Oxygen Basic

Programming => Bugs & Feature Requests => Topic started by: helloworld on May 20, 2017, 06:18:46 AM

Title: more bugs..
Post by: helloworld 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
Title: Re: more bugs..
Post by: Arnold 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.
Title: Re: more bugs..
Post by: Charles Pegge 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.
Title: Re: more bugs..
Post by: helloworld 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
Title: Re: more bugs..
Post by: Charles Pegge 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.
Title: Re: more bugs..
Post by: Charles Pegge on June 02, 2017, 01:42:33 AM

Okay, colon separators are now supported in type and class definitions. (May 31 2017)
Title: Re: more bugs..
Post by: helloworld 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
Title: Re: more bugs..
Post by: Charles Pegge 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
Title: Re: more bugs..
Post by: Mike Lobanovsky 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! :)
Title: Re: more bugs..
Post by: Charles Pegge 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
Title: Re: more bugs..
Post by: edcronos 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
Title: Re: more bugs..
Post by: helloworld 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?

Title: Re: more bugs..
Post by: Aurel 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
 ::)
Title: Re: more bugs..
Post by: Charles Pegge 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.
Title: Re: more bugs..
Post by: Charles Pegge 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.
Title: Re: more bugs..
Post by: edcronos on January 03, 2018, 10:12:31 PM
yes I like it I use to get out of nested loops
but also have some not-so-noble uses as say the gotophobics

despite the non-need of usage nowadays, I think gosub can save some processing cycles in place of function calls.
at least in vba when I took the gosub and added functions it got remarkably slower, I even preferred to put the command lines inside the macro itself repeating everything inside the loops

Title: Re: more bugs..
Post by: Charles Pegge on January 04, 2018, 04:32:36 AM

gosub is very efficient. It is almost identical to an assembler call, and does not have the prolog and epilog code required by functions. It should always be available in a Basic compiler.
Title: Re: more bugs..
Post by: JRS on January 05, 2018, 12:28:03 PM
Does O2 have a POP like keyword to exit a GOSUB without a RET?
Title: Re: more bugs..
Post by: edcronos on January 05, 2018, 01:24:27 PM
but gosub is to function as an internal function, and does every fuction have to have an end function or not?

gosub as well as goto is very frowned upon, maybe a lot more than goto
I find it useful in constructions when you have many nested instructions because the editor does not close pieces, but as soon as I remove the gosub

or when you do not want to create a function that will not be useful outside of that macro and besides having multiple calls you have to deal with many variables

as I said so I started vba I did not know what was functions so I used gosub,
in something like this:
Code: [Select]
     For w = 1 To k
          'Origem --( Leitura )--
          If Op = 0 Then GoSub OCoL: If T = 1 Then T = 0: GoSub OLin
          If Op = 1 Then GoSub OLin: If T = 1 Then T = 0: GoSub OCoL
          Ddo = Cells(Loi, Coi).Value2

          'Destino --(Escrita )--
          If Dp = 0 Then GoSub DCoL: If T = 1 Then T = 0: GoSub DLin
          If Dp = 1 Then GoSub DLin: If T = 1 Then T = 0: GoSub DCoL
          Cells(Ldi, cdi).Value2 = Ddo

     Next
     ''-----------------( Fim do loop )----
     GoTo saida

  '----------------------------( ORIGEM )------------
OLin:
     If Op = 0 Then
...
 Else
...
                    If Oquadante_L = True Then GoSub OCoL:
...
                    Else
...
                    If Oquadante_L = True Then GoSub OCoL:
      End If
     Return

OCoL:          '----( Controle de colunas )---
     If Op = 0 Then
...
GoSub OLin:
...
          Else
...
 GoSub OLin:
...
Else
    GoSub OLin:
     End If
     Return

     '---------( DESTINO )-----------
DLin:
     If Dp = 0 Then
...
 GoSub DCoL:
   Else
...
If Dquadante_L = True Then GoSub DCoL:
...
          Else
...
If Dquadante_L = True Then GoSub DCoL:
...
     End If
     Return

DCoL:
...
GoSub DLin:
...
          Else
GoSub DLin:
  End If
 Return

and the call of each function should be something like this
        Call funOCoL(Op, Loi, OLi, OLf, OqL, Lig, OZigL, Oquadrante_L, Coi, OCi, OCf, OqC, Cig, OZigC, Oquadrante_C, T)

but in general using functions is much more practical
Title: Re: more bugs..
Post by: Charles Pegge on January 05, 2018, 02:47:02 PM
John,

You can have multiple rets from a gosub. Unlike a function, there is no formal termination. It compiles straight into assembly code without hidden extras.

It is also possible to pop the return address but this hack is cursed by the 64bit 16byte stack alignment protocol. However, You can allow the gosub routine to drop thru to end function without ret. The parent function epilog will automatically clean up the stack before the parent function is terminated.

Code: [Select]
int a=5,b=10
gosub sumif
print a
end

sumif:
if a<=5 then ret
a+=b
ret

Eduardo,

There are no restrictions with a gosub, which is probably why they are so reviled. As you say, gosubs share the variables of the environment where they are defined, unlike functions which require parameters.

Macros are also very useful. They are even faster and take parameters.

In both gosubs and macros, private variables can be defined inside a scope block. So you can achieve the encapsulation benefits of functions.
Title: Re: more bugs..
Post by: edcronos on January 05, 2018, 03:25:10 PM
Charles, I do not understand what you mean by restrictions,
a single poorly defined variable can give a lot of headache

in this macro with gosub that allocates data from one array to another "Ranges" I had several problems with it by drawing up geometric figures with the data in the target array "something I can never reproduce"
and I suffered to adjust the adjustments of the variables
Title: Re: more bugs..
Post by: JRS on January 05, 2018, 05:03:57 PM
Here is how it works under Script BASIC.

Code: Script BASIC
  1.  
  2. GOSUB Go_Sub
  3.  
  4. END
  5.  
  6. Go_Sub:
  7.   POP
  8.   GOTO Done
  9. RETURN
  10.  
  11. Done:
  12. PRINT"Exited GOSUB without a RETURN stack error.\n"
  13.  


jrs@jrs-laptop:~/sb/examples/test$ scriba pop.sb
Exited GOSUB without a RETURN stack error.
jrs@jrs-laptop:~/sb/examples/test$

Title: Re: more bugs..
Post by: edcronos on January 05, 2018, 07:12:16 PM
I did not understand John,
how do you get out of a function without going back to the program that called it?
I even have a Sub Control that is called by most of the sub from a spreadsheet I made, and I had to add a control variable to determine the neutral
the gosub I think that one has to determine the functionalities and if it has to give sequendia to use a variable, in the case I used the variable T of tests to inform that the function had a change of value in the variables

Code: HTML5
  1.  
  2. GOSUB Go_Sub
  3.  if t=0 then GOTO Done
  4. ...
  5. END
  6.  
  7. Go_Sub:
  8. ...
  9.  if fails then t=0
  10. RETURN
  11.  
  12. Done:
  13. PRINT"Exited GOSUB without a RETURN stack error.\n"
  14.  
  15.  
Title: Re: more bugs..
Post by: JRS on January 05, 2018, 08:30:00 PM
Quote
how do you get out of a function without going back to the program that called it?

GOSUB is not calling a function. It jumps to a LABEL and when it sees the RETURN it executes the line after the GOSUB that called it unless you use a POP before exiting without returning.
Title: Re: more bugs..
Post by: edcronos on January 05, 2018, 11:48:44 PM
initially was to simulate function calls,
but of course it would be nice to have other facilities,
but in this case, how do you get nested calls?

Of course I would like to have goto and gosub with labels inside variable
but I do not know if it's possible, and I can not want everything
Title: Re: more bugs..
Post by: Charles Pegge on January 06, 2018, 03:09:22 AM
Macros can replace small functions and gosubs very effectively, without using the stack and the expense of setting up stack frames for local variables.

Macros can be defined anywhere, even inside functions for local use.

Code: [Select]
macro limit(a,b)
  if a>b then goto done
end macro

int x=1
do
  limit(x,10)
  x+=3
end do
 
Done:
PRINT"Exited GOSUB without a RETURN stack error.\n"
Title: Re: more bugs..
Post by: edcronos on January 06, 2018, 04:11:16 AM
I'm reading about macros and subroutines
but it is a strange concept for me, I did not quite understand the relation of scope to internal variables.
I do not know if it's what you intended using sub inside of sub, in case it would be something like a call taking advantage of the same scope of variables
well, I'm going to pick it up, anyway my use is very limited

a question, what kind of code example is interesting to post?
Title: Re: more bugs..
Post by: JRS on January 06, 2018, 10:38:49 PM
BASIC Interpreters are easier to deal with GOSUB as in most cases variables are of a global scope, Script BASIC function/sub arguments are local but can easily refer to global variables within functions or subs. The LOCAL keyword is provided to isolate variables to a routine. The MODULE/END MODULE scope is a form of name space. Functions and variables in modules must be prefixed by the module name and :: for access from the MAIN:: script.

Code: Script BASIC
  1. ' MAIN
  2.  
  3. a = "Hello from MAIN::"
  4.  
  5. MODULE This
  6.  
  7. a = "Hello from This::"
  8.  
  9. END MODULE
  10.  
  11. PRINT MAIN::a,"\n"
  12. PRINT This::a,"\n"
  13.  


jrs@jrs-laptop:~/sb/examples/test$ scriba scope.sb
Hello from MAIN::
Hello from This::
jrs@jrs-laptop:~/sb/examples/test$


Note:  The MAIN:: prefix is optional in Script BASIC as it would make the program overly verbose. The syntax is supported if you can find a use.
Title: Re: more bugs..
Post by: edcronos on January 07, 2018, 10:49:50 AM
is almost equal to vba
being that in vba the modules are physical but variable and procedures are seen,
  except as Private when only other procedures, from the same module see them, but do not replace internal variables with procedures

  and Global usage replaces any variable with the same name, something that has to be very careful but can serve as key variable
Title: Re: more bugs..
Post by: JRS on January 07, 2018, 11:56:43 AM
Quote
s almost equal to vba

Actually SB is more like VBA then most people think. Checkout what I'm doing with SB on the Open Sage Forum (http://opensage.org).
Title: Re: more bugs..
Post by: edcronos on January 07, 2018, 01:09:59 PM
what I'm noticing is that there is a kind of competition between the various versions of Basic, it does not make sense because they are completely independent and without a compatible base, someone who is going to build an IDE will have to choose one of several versions.

as I said my use is only hobby and with specific direction, besides being very limited
  if Oxygen had a more complete Ide I would have spent a bit of what I have for a dll because all I do is only with If's Loops and Arrays with very little variation
SB seems to be cool and well competent but from what I've read it's an interpreter, although I do not know if Oxygen is a true compiler or just a pseudo
Title: Re: more bugs..
Post by: Charles Pegge on January 07, 2018, 01:29:57 PM
Eduardo, you can post any type of code you would like to share. It does not even have to be Basic if there is something of interest in it.

OxygenBasic uses namespace. It performs the same role as ScriptBasic's module, with the same double-colon naming scheme.
Title: Re: more bugs..
Post by: edcronos on January 07, 2018, 02:30:48 PM
You're trying to make me madder than I already am.
I was thinking that module was from Oxygen "so in the attempts here was giving error"
the SB has plenty of practical examples which makes it much easier.

you could set a foothold for Basic,
type syntax, structure, basic functions that can not be missing, types of variables ...
or include a "replacement" translation table,
  this would give the project a lot more power than each going in one directionection
Title: Re: more bugs..
Post by: JRS on January 07, 2018, 09:11:34 PM
Quote
You're trying to make me madder than I already am.

Being mad at people that create tools and share the source freely is not an approach that is going to get you very far.

Title: Re: more bugs..
Post by: JRS on January 07, 2018, 09:16:09 PM
Quote
OxygenBasic uses namespace. It performs the same role as ScriptBasic's module, with the same double-colon naming scheme.

DLLC magically brings all the features of O2 to the Script BASIC scripting engine.  8)
Title: Re: more bugs..
Post by: edcronos on January 07, 2018, 09:21:22 PM
Quote
You're trying to make me madder than I already am.

Being mad at people that create tools and share the source freely is not an approach that is going to get you very far.

this was a meaning conversion error
in the case is something like leaving confusing, disturbed of ideas
  because I was concluding that everything written was about the oxygen
Title: Re: more bugs..
Post by: JRS on January 07, 2018, 09:47:22 PM
As strange as it may seem, everything on Google isn't about Google.
Title: Re: more bugs..
Post by: Charles Pegge on January 07, 2018, 10:56:58 PM
The most important thing is that the language allows you to compose code which is direct and easy to read.

In this regard, popping a sub, or continueing a for loop, can be a bit tricky when checking a piece of code for runtime errors, especially if it is not your own code.

ADA is an interesting language. Design for safety-critical applications, it is more verbose than Basic, but very easy to read, without prior knowledge of the language itself.
Title: Re: more bugs..
Post by: edcronos on January 08, 2018, 04:12:42 AM
I'd better try my best on oxygen.
Title: Re: more bugs..
Post by: edcronos on January 11, 2018, 02:16:28 AM
Eduardo, you can post any type of code you would like to share. It does not even have to be Basic if there is something of interest in it.

OxygenBasic uses namespace. It performs the same role as ScriptBasic's module, with the same double-colon naming scheme.

I'm still finishing some things I've already started on VBA
but looking at the examples posted I do not believe I have something useful that goes to the oxygen and can post
What I do is just a few crazies aimed at lotteries,, even if I'm not a gambler, it's just for the same hobby