Author Topic: more bugs..  (Read 2951 times)

0 Members and 1 Guest are viewing this topic.

helloworld

  • Newbie
  • *
  • Posts: 16
more bugs..
« on: May 20, 2017, 06:18:46 AM »
Code below [oxygen.dll ver. A43] will not compile unless object's name is 'b' :D

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

  • Hero Member
  • *****
  • Posts: 648
Re: more bugs..
« Reply #1 on: May 20, 2017, 01:11:23 PM »
Quote
... 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

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #2 on: May 20, 2017, 02:25:48 PM »

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

  • Newbie
  • *
  • Posts: 16
Re: more bugs..
« Reply #3 on: May 24, 2017, 10:30:00 AM »
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

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #4 on: May 24, 2017, 06:37:43 PM »

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

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #5 on: June 02, 2017, 01:42:33 AM »

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

helloworld

  • Newbie
  • *
  • Posts: 16
Re: more bugs..
« Reply #6 on: December 31, 2017, 05:41:56 AM »
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
« Last Edit: December 31, 2017, 05:56:15 AM by helloworld »

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #7 on: December 31, 2017, 07:26:25 AM »
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

  • Admin Support Member
  • *****
  • Posts: 1855
Re: more bugs..
« Reply #8 on: December 31, 2017, 09:25:58 AM »
... continue the nearest construct, which happens to be the if statement.

Wow! continue if:o

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...


Quote
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! :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, 2 x nVidia GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #9 on: December 31, 2017, 09:50:00 AM »
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

  • Guest
Re: more bugs..
« Reply #10 on: December 31, 2017, 02:47:12 PM »
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
« Last Edit: January 01, 2018, 04:19:12 AM by edcronos »

helloworld

  • Newbie
  • *
  • Posts: 16
Re: more bugs..
« Reply #11 on: January 02, 2018, 01:09:35 AM »
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

  • Sr. Member
  • ****
  • Posts: 256
Re: more bugs..
« Reply #12 on: January 02, 2018, 03:42:56 AM »
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

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #13 on: January 03, 2018, 04:09:16 AM »

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

  • Admin Support Member
  • *****
  • Posts: 3721
    • Oxygen Basic
Re: more bugs..
« Reply #14 on: January 03, 2018, 04:31:57 AM »
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.