Page 1 of 1
Hello
Posted: Tue Nov 23, 2021 12:48 pm
by aurel
hello again
So this one would be for Linux...that is fine
well i am not Linux user very much but i like concept.
Re: Hello
Posted: Tue Nov 23, 2021 12:58 pm
by frank
aurel wrote: ↑Tue Nov 23, 2021 12:48 pm
hello again
So this one would be for Linux...that is fine
well i am not Linux user very much but i like concept.
With NASM installed on Windows, it shouldn't be difficult to port. But the library must support Windows system calls too. This is not difficult and will be implemented along with compiler directives once the basic compiler is complete and functional. This will likely take a few more months as floating point numbers and arrays have not been implemented yet.
Re: Hello
Posted: Tue Nov 23, 2021 4:02 pm
by aurel
Of course i understand
i build few toy interpreters and never compiler ,assembly ..ouhhh i don't get it
it is not easy work , even i am working (from time to time ) on my small interpreter
i still not have arrays ..hmm i am in doubt how to add them ,i know ways but i am not sure what
would be better ..so keep on
Re: Hello
Posted: Tue Nov 23, 2021 6:15 pm
by frank
aurel wrote: ↑Tue Nov 23, 2021 4:02 pm
Of course i understand
i build few toy interpreters and never compiler ,assembly ..ouhhh i don't get it
it is not easy work , even i am working (from time to time ) on my small interpreter
i still not have arrays ..hmm i am in doubt how to add them ,i know ways but i am not sure what
would be better ..so keep on
The advantage of learning ASM is that concepts such as arrays become easier to understand and implement. Same goes for structs/types.
Re: Hello
Posted: Tue Nov 23, 2021 7:19 pm
by aurel
yeah ..but i really don't have a time to learn assembler
it is too hard to me or i am lazy ..i understand very well concepts but again i am too lazy to type all
that code even in BASIC compiler which i use Oxygen Basic ..by the way it is written in Freebasic
ahh i will see..
Re: Hello
Posted: Tue Nov 23, 2021 7:24 pm
by aurel
before current interpreter microA i made one called ruben
that one have arrays and worked well but little bit slow ..i know why
i interpreter such is my i avoid variable lookup routine using separate array to hold var ID
so same method i will try to use in current ...
for compiler things are very different ...
Re: Hello
Posted: Fri Nov 26, 2021 5:37 pm
by aurel
I just viewed ...
you use "==" for
if statement 
why is that .....pascal,C or mix ??
why simply is not just
=
Re: Hello
Posted: Fri Nov 26, 2021 5:55 pm
by frank
aurel wrote: ↑Fri Nov 26, 2021 5:37 pm
I just viewed ...
you use "==" for
if statement
why is that .....pascal,C or mix ??
why simply is not just
=
While developing the expression parser last year I realized why 'mature' languages such as Pascal and C use different operators for assignment and comparison. Key is boolean expression evaluation. With statements such as:
one is easy enough to tell from the other. But what if:
Does it mean that a, b and c are equal or that a is true if b and c are equal? This is an ambiguous situation. So for the expression parser (and for the programmer) it is much easier to have different operators for assignment and comparison so that:
and (if allowed):
are unambiguous.
A programming language that knows little to no ambiguous situations can be more powerful with more features and is easier to use and develop.
Re: Hello
Posted: Sat Nov 27, 2021 6:34 pm
by aurel
My point is that average BASIC programmer don't like ==
and who use this constructs
like
a=b=c ...no one !
from the boolean expression it is perfectly same
i have as many other Basics just
if a = b : print a : end if ../ or endif
not
if a ==b : print a : end
but of course you work your way
i have for example
func name()
...
...
endFn
'events...
WinMsg wmKEYDOWN
hWparam wp
endWM
Re: Hello
Posted: Sat Dec 04, 2021 6:17 pm
by frank
aurel wrote: ↑Sat Nov 27, 2021 6:34 pm
My point is that average BASIC programmer don't like ==
and who use this constructs
like
a=b=c ...no one !
I beg to differ. Expressions expecting a boolean result are plenty:
Code: Select all
dim test: bool;
dim b, c: int = 10;
test = b = c; ' perfectly legal test, but ambiguous with a single operator for assignment and comparison
test = b == c; ' perfectly clear what this is about.
Lesson number 1: don't make it harder for the compiler than necessary. Both expressions can be allowed with different results (in
SharpBASIC the first expression is not allowed because an assignment operator inside an expression is illegal).
BASIC programmers have become used to 'easy' programming, but it also gave the language a bad reputation.
The consistency of the 'is-equal' operator (==) as far as
SharpBASIC is concerned, lies in its counterpart operator 'not-equal' (<>); both use two characters and there's a symmetry between them.
SharpBASIC is called 'sharp' for a reason. It's
not meant to be 'just another BASIC' language.
