more bugs..

[helloworld]

Code below [oxygen.dll ver. A43] will not compile unless object's name is 'b'

Also, a situation like: <statement><colon><another statement> will not compile (i.e. "int a:int b"); have to leave at least one space inbetween (i.e. "int a :int b").

Code: [Select]

class aclass
method constructor : end method
method destructor : end method
end class

new aclass o
del o


[Arnold]

... will not compile (i.e. "int a:int b")

I myself would see this as a feature, not as a bug. I always set a space before and after the :. And I assume a: could be interpreted as a label under some circumstances. Nevertheless using win32 (win64 not tested) this will work on my system:

int a:int b
print a:print b

I get two messageboxes with 0.

I think the usual way to declare the variables would be: int a,b or: int a, int b. Another way would be: dim a as int, b as int.

[Charles Pegge]

I have been able to make the parser a little more discriminating. The spacing between the first word and a colon in the line, is used to determine whether the first word is a label, or another kind of symbol (such as a procedure or macro call).

As well as labels with attached colons, we also have NameSpace prefixes with double colons, for instance graphics::clear. Also Assembler segment override prefixes DS: [ebx+0x40]

So keeping your colon separators separate is generally a good idea

The del bug, and a few others I hesitate to mention are also fixed. Well done for diagnosing the problem!

Will post the update early tomorrow.

[helloworld]

Will post the update early tomorrow.

However, now this does not work anymore:

Code: [Select]

class aclass
int a : int b
method constructor : end method
method destructor : end method
end class
new aclass o
del o

Whereas this does:

Code: [Select]

class aclass
method constructor : end method
method destructor : end method
end class
int a : int b
new aclass o
del o


[Charles Pegge]

helloworld,

The normal type syntax, used by classes, does not expect colon separators. The expected format is:

int a,b

Bit fields (an arcane C construct)  are accepted but not implemented:

int a : 4

But I will see if we can safely allow colon separators between members.

[Charles Pegge]

Okay, colon separators are now supported in type and class definitions. (May 31 2017)

[helloworld]

Hi,
"continue" statement causes the program to hang [oxygen.dll ver. A43]:

Code: [Select]

i=0
while i<5
if i==3 then continue
i++
wend
print i


[Charles Pegge]

Helloworld,

Yes, without specifying what is to be continued, it will continue the nearest construct, which happens to be the if statement.

You must continue while or continue do, but I may change the semantics to comply with C usage

[Mike Lobanovsky]

... continue the nearest construct, which happens to be the if statement.

Wow! continue if! 

Though I can sense some, uh, sense in being able to continue evaluation in select-case or multi-if constructs where the selector variable may change in the process of evaluation in a particular case or else if statement...

continue while or continue do, but I may change the semantics to comply with C usage

Should you? I don't find C-style anonymous continue or break particularly handy. Contrary to that, continue while/do looks very elegant in doubly nested loops though it can also be ambiguous, e.g. as in

Code: [Select]

while cond_1
    while cond_2
        ....
        continue while
    wend
wend
Which of the two (or more) nested while's you effectively wish to continue?

My solution in FBSL v3.5 was to also make continue accept numeric nesting level indexes as follows:

-- anonymous continue iterates the loop it immediately appears in
-- continue while/do iterates the exact while or do in a stack of two nested while/do or do/while loops
-- continue 0 ... n iterates the loop index n in a stack of multiply nested loops regardless of whether the indexed loop appears to be a while or a do

whereby anonymous immediate continue is the same as continue 0.


Have a great New Year time, everyone!

[Charles Pegge]

Hi Mike,

We can do this in low-level blocks with exit and repeat (1..n) nesting index, but not in Basic blocks.

Code: [Select]

(
 (
  exit 2
  repeat 2
 )
)


I agree that the anonymous C continue and break is problematic, but with a little extra parsing, it is do-able. break will exit a do block or a case block. The case block has priority. continue will work for the innermost do or while

[edcronos]

For things like that I wonder why people get so involved with Goto.

In the past, we had no way to create functions, to separate by functional block,
so we had to use goto to jump from one to the other,
1000, 2000 ... lines with goto playing from here to there and back, it really is something that shuffles the rationale

but nowadays it's just an extra function, used only in small chains of commands that is far from disturbing the understanding of functionality,
which can make logic easier or even make code faster by ignoring loops and cascading conditions.

gosub I have no idea if it can really be useful nowadays, or if it gets slower or faster than function calls with passing parameters.
I like to use to facilitate the logic of what I'm doing, but then I shoot.
 or when you have a feature that will be used many times but only by this macro,

of course I've done something crazy like using gosub's inside a loop as if they were calling functions to each other depending on the request, I got redo using function and with more parameters but I lost with my HD,

but I think that each one has a different view of things, besides the logic and different nescessidades

a happy new year for everyone
that oxygen serves as an oxidizer for new ideas

[helloworld]

Helloworld,

Yes, without specifying what is to be continued, it will continue the nearest construct, which happens to be the if statement.

You must continue while or continue do, but I may change the semantics to comply with C usage

However, even if I modify the program like so, it does not help.
Also, I wonder why there seem to be no continue with for loops?

[Aurel]

Wait a moment...
break and continue are not part of BASIC like language and as such from
my perspective are USELESS
why boother when we have
EXIT for
exit while
exit do
 

[Charles Pegge]

Helloworld,

continue for works but does not advance the iterator. I will fix this on the next (beta) release, though I think the construction would be cleaner, as a general rule, using a while or do loop.

[Charles Pegge]

Hi Eduardo,

Goto is a very useful instruction, especially for large loops. There is no benefit in nesting major loops which may run for thousands of lines.

In OxygenBasic, due to its scoped nesting protocol, it is not possible to goto or jump into the interior of a nested block. The only way in is at the start of the block. But you can jump out at any point.

Gosubs are supported. They end with ret instead of return, which is reserved for functions and subs.