Hello

This is the place to share ideas, likes and dislikes of the SharpBASIC language
Post Reply
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Hello

Post 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.
User avatar
frank
Site Admin
Posts: 27
Joined: Sun Nov 21, 2021 12:04 pm
Location: Netherlands
Contact:

Re: Hello

Post 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.
Keep it simple!
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Re: Hello

Post by aurel »

Of course i understand
i build few toy interpreters and never compiler ,assembly ..ouhhh i don't get it :o
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 :)
User avatar
frank
Site Admin
Posts: 27
Joined: Sun Nov 21, 2021 12:04 pm
Location: Netherlands
Contact:

Re: Hello

Post 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 :o
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.
Keep it simple!
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Re: Hello

Post 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..
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Re: Hello

Post 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 ...
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Re: Hello

Post by aurel »

I just viewed ...
you use "==" for if statement :shock:
why is that .....pascal,C or mix ??
why simply is not just =
User avatar
frank
Site Admin
Posts: 27
Joined: Sun Nov 21, 2021 12:04 pm
Location: Netherlands
Contact:

Re: Hello

Post by frank »

aurel wrote: Fri Nov 26, 2021 5:37 pm I just viewed ...
you use "==" for if statement :shock:
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:

Code: Select all

a = b
if a = b ...
one is easy enough to tell from the other. But what if:

Code: Select all

a = b = c?
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:

Code: Select all

a = b == c
and (if allowed):

Code: Select all

a = b = c
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.
Keep it simple!
aurel
Posts: 11
Joined: Tue Nov 23, 2021 12:18 pm

Re: Hello

Post 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
User avatar
frank
Site Admin
Posts: 27
Joined: Sun Nov 21, 2021 12:04 pm
Location: Netherlands
Contact:

Re: Hello

Post 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. ;)
Keep it simple!
Post Reply