Author Topic: Some thoughs on implementation.  (Read 2524 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Guest
Some thoughs on implementation.
« on: January 13, 2019, 10:00:39 PM »
 I have been tackling some issues i have encountered. There are some solutions that i am happy with, and some others, not so much.

 Overall, i am enjoying working with oxygen, and the fact that there is no help available, is kind of the salt to the challenge, making it even more enjoyable. Some times i need to go back and do it better because i am presented with a method that is better than what i was doing, because there is not help file, but thats ok.

 Some of the things i wonder why where implemented the way they were in oxygen are... shared equates. For example, i am used to being able to use this:

Code: [Select]
$EXTRA = "SOMETHING"
%EXTRA = 12345

 No collisions, everything is fine. However, with Oxygen, a string constant has exactly the same name than a numeric one, making it necessary to add some kind of disctintive. So, lets say there is a constant named Extra, then no local or global variables, functions, classes, unions or Types can be created with that name.

 So, in order to allow this, i had to add a prefix to each constant, numeric, string and wstring equates. This way there are no collisions. However, when trying to use one of this equates in RAW blocks, it will not be as intuitive, because, when an equate is defined as %extra, in a RAW block it will be required to refer to it as _20EXTRA. I have no problem adding a prefix for internal stuff that the end programmer does not need to touch, but for this i would rater like to do it some other way.

I have more thoughts but something has come up while redacting this, so i will continue in the morning. :)

Brian Alvarez

  • Guest
Re: Some thoughs on implementation.
« Reply #1 on: January 14, 2019, 10:35:51 AM »
For example, take a look at this code:

https://forum.powerbasic.com/forum/user-to-user-discussions/powerbasic-for-windows/47474-on-screen-ruler/page3

 As you can see there is an equate named %POINT, converting it literally would collide with the TYPE POINT, so, a distinctive was required.
A lot of existing code has such collisions.

Charles Pegge

  • Guest
Re: Some thoughs on implementation.
« Reply #2 on: January 18, 2019, 02:06:16 AM »
Hi Brian,

At the outset of o2 development, I anticipated that $ ? % Basic symbol endings would eventually go extinct :)

But if you need to represent them internally, these endings could be transposed into upper ascii by adding 96 to the ascii code.

o2 allows ascii codes 128..239 to be used as alpha characters. (240..255 reserved).

Brian Alvarez

  • Guest
Re: Some thoughs on implementation.
« Reply #3 on: January 18, 2019, 01:21:15 PM »
In some of the most modern languajes, the character case is a gobally accepted disctintive, for example, variable name "isAcute", "ISACUTE" and "IsAcute" are understood that there are different things represented by the name. It is common knowledge. Its like an untold rule we all follow.

 BASIC is different, because there is no character case distinction. So, the diferentiator needs to be something else. Thats why there is a need for symbols. I think having non-case sensitive variables, and non symbolized stuffs is an unneeded and self-imposed limitation, but there are tastes for everybody. :)

 If you decide to go through the non-case sensitive way, i agree symbols may become useless at some point. For the case sensitive path, symbols are a need. IMHO.

JRS

  • Guest
Re: Some thoughs on implementation.
« Reply #4 on: January 18, 2019, 03:47:59 PM »
If O2 takes the variant route (like SB) then suffix type indicators are legacy reminders. I was happy to see Charles introducing O2 variants in the latest OXSC build. The low level COM and maybe automation now has real possibilities. Maybe Mr. Roca will rejoin us. The maintainer offer for the O2 sandbox is still on the table.

Aurel

  • Guest
Re: Some thoughs on implementation.
« Reply #5 on: January 18, 2019, 11:24:56 PM »
Please
 ..stop making C like language from BASIC like language ...
case sensitivity is stupid thing...
i know this when i recently work in C

HWND hwnd;

what a heck is this ...yes this is the way in C.

Brian Alvarez

  • Guest
Re: Some thoughs on implementation.
« Reply #6 on: January 19, 2019, 12:55:15 PM »
 Hehe, yeah. Its weird for the ones that are not used to this. For someone who is used to this, this is no brainer. As much as i like BASIC, I would be limiting myself if i only knew BASIC though.

JRS

  • Guest
Re: Some thoughs on implementation.
« Reply #7 on: January 19, 2019, 06:06:33 PM »
Quote
I would be limiting myself if i only knew BASIC though.

That would be like trying to live on Big Macs and fries.

Charles Pegge

  • Guest
Re: Some thoughs on implementation.
« Reply #8 on: January 22, 2019, 12:44:07 AM »
Hi John,

Variants will be supported by the new operations system. I am still tuning it. Variants are processed with API functions like VarClear, VarAdd, VarMul, VarCopy. The task is to turn expression notation like A=B+C*D into a series of these API calls.

JRS

  • Guest
Re: Some thoughs on implementation.
« Reply #9 on: January 22, 2019, 01:02:27 AM »
Nice!

Worth waiting for.

Brian Alvarez

  • Guest
Re: Some thoughs on implementation.
« Reply #10 on: January 22, 2019, 01:22:07 AM »
...Variants will be supported by the new operations system...

 :o

Wow! Thats gonna be a hit! :D Thanks Charles!

 Are runtime errors going to be reported or just ignored? I mean, when a variant holding a string is used in an arithmetic operation will the error be reported or just 0 be used? or string contents used as value? It will be for sure interesting to see your implementation! Looking forward to it!

Aurel

  • Guest
Re: Some thoughs on implementation.
« Reply #11 on: January 22, 2019, 02:09:36 PM »
And all this should be simplier if we have type POINTER