Oddity with colon

[Arnold]

Hi Charles,

I compare some console demos that contain keywords from different BASIC dialects and how they could be developed in Oxygenbasic. Unfortunately I have only learned GW-Basic in the past and still suffer from it, though I have probably made some progress in this respect thanks to O2.

In this example (derived from BCX) I apply the use of `:` to concatenate several statements in one line. This works qute nice with one exception in line 53: Oxygenbasic refuses to accept :cls: (:cls : or :cls(): will work):

Code: [Select]

                 ':cls:  does not work?
dim a:setcolor 7,0:cls :for a=1 to 23:print "This is line number "a:print cr:next:print "This is line number "a++:print "  Enter ...":call panel(5,10,20,20,15,1,32,0):locate 1,50,0:waitkey:call panel(5,10,20,20,15,4,32,1):locate 1,1,0:waitkey:cls

The error message is:
ASSEMBLER:
ERR:   cls!! Unidentified instruction: cls
LINE:  53
FILE:  "main source"

At first I thought O2 would see :cls: as a label. But on the other hand :next: and :waitkey: are accepted. Could there be another reason why :cls: throws an error message?

Roland

[jcfuller]

Roland,
  While This is only my personal opinion (I have programmed in many versions of BASIC) I NEVER use colons to concatenate several statements in one line. It makes it too hard to follow and to tell the truth I never really saw the reason behind it?
I also never use single line if statements for the same reason.

James

[Arnold]

Hi James,

I know I am exaggerating a bit. I personally use colon with spaces left and right if I use two or three statements in a line.

But you certainly noticed that I started to port the BCX console demos to Oxygenbasic (there are still about 80 examples left) and this works remarkably well until now. I want to see which library functions of Oxygenbasic I can use to create the apps and what functions / subs need wrapping. I think BCX is very complete in using the console.

My only purpose is to notify Charles if I find a discrepancy. I do not expect a solution at any rate. Most of the time there are alternative ways. Yet perhaps a finding at one point could help with another problem. It is just a guess.

Roland

[Arnold]

I made a further test, replaced waitkey with getkey and got also an error message. So I now understand what happens. It is not a big problem, but it is helpful to know that there is a difference sometimes between functions/subs and macros. And if I think more about it, I come to the conclusion that getkey() and cls() is actually the correct notation.
 

[Charles Pegge]

Hi Roland,

I will restrict label identification to avoid confusion with unspaced colons as statement separators.

[Arnold]

Hi Charles,

personally I think there is some logic in the error message of Oxygenbasic, I only did not see the reason at the first moment. ProcName() is the correct way, ProcName is for convenience, which will not work in all cases. By porting some of the demos with basic like syntax I found similar cases like function name$() ... which will work sometimes with $, sometimes not, also sometimes calling ProcName a,b,c does not work, but using parenthesis solves the problem. Probably there are some more cases, but I did not check extensively. I think the error messages can really be helpful, they only need to be interpreted correctly.

Perhaps it is possible to add a section in the Oxygen Helpfile about some differences to other languages, about error messages and the possible causes and solutions? Over time, this chapter could be expanded. Other programming languages which are a lot stricter in the syntax rules than Oxygenbasic and by far not so flexible also need to explain their error codes, and sometimes it takes some time nevertheless to find out what went wrong.

Roland

[Mike Lobanovsky]

By porting some of the demos with basic like syntax I found similar cases like function name$() ... which will work sometimes with $, sometimes not, ...

NB: In BCX and its derivatives, somename$() (string args and/or return) and somename() (numeric args and/or return) are distinct functions or language keywords rather than in situ casts of the same function. You can't mix them at will. You're supposed to match an appropriate function variation with the data you're feeding it. Unlike O2, BCX & Co. wouldn't attempt transparent automatic conversion for you in such cases.

[Charles Pegge]

As this seems to be a persistent issue, I can make !#$%& word endings significant instead of ignoring them.

[Mike Lobanovsky]

... I can make !#$%& word endings significant instead of ignoring them.

If you go the BCX way, that will make O2 type checking much stricter than it is now, and as such, much farther away from what a classic BASIC-er would expect. BCX is only a B2C translator and it does only what is more natural for the target language. I'd do that only if I weren't absolutely sure my code can efficiently handle all the implied conversions transparently to the user.

But granted it's also going to make life easier for the language developer, although harder and more error-prone, for the user.

OTOH if what you mean by your statement is going to be yet another cast scheme, then I'd vote for it because if 100% consistent and unambiguous throughout the language, it will then be the ultimate shorthand notation for forcible data type conversion I'm aware of.

[jcfuller]

Roland,
  I'm not sure you are aware but many of the BCX runtime functions use optional parameters meaning the translated "c" can only be compiled with Pelles C. I don't remember if O2 is compatible?
James

[Charles Pegge]

Hi Mike,

I'm allowing these characters to be used anywhere in any name except for the first position, but not attributing any type-semantics to them.

For example, these names would be treated as distinct:

a
a%
a$
a$$

[Mike Lobanovsky]

@Charles:

Oh, I see. You're just expanding the set of significant characters allowable in a name.

@James:

Yes, O2 supports optional parameters too.

[Charles Pegge]

There are a few parsing consequences.

Some expressions will now require spacing:

a=b&c
a=b & c

if a!=b
if a != b

Core string functions may need to be dollified:

def str$ str
def left$ left
def space$ space
...

[Aurel]

My point is :
don't change anything... why ?
simply because i always get in trouble with when you made some changes 
 

colon work for me fine

label:

mylabel:

I don't know if o2 have keyword label ?
...anyway ...because of unexpected changes i like to use stable version 043 

ps ...to be perfectly clear ..i don't use console for anything

[Arnold]

Hopefully I will not be misunderstood. Nowadays I can solve so many tasks with Oxygenbasic, which I could not do before. I myself do not need the suffixes and will not use them. When I started with Oxygenbasic and did not know much about other Basics, I fortunately found in the O2 examples most of the time declarations like: int a, float b, string s etc and: function name, sub name. This was sufficient for me to understand what types were used and how they were processed.

But since I noticed that O2 is tolerant to some extent in syntax, I am tempted from time to time to find the limits. And there are already limits with dim:

Code: [Select]

dim a     'int/sys?
dim b%    'int/sys?
dim c!     
dim d#    'int/sys?
dim e$    'int/sys?

'freebasic $lang: "qb"
dim f&=4   : print f& ""

a=5
b%=6
'c! = 2.4  'error
d#=2.57   
e$="Hi"
f&=7.6   

print a ", " b% ", " d# ", " e$ ", " f&  "" 'concatanation


Implicit declaration by adding a type character looks strange to me. Such a declaration should already be a bug in Oxygenbasic.