Loopy bugs

[pjw]

The online SuperBasic manual has some interesting comments on FOR loops -
including how different ROMs will process some FOR statements differently.
And some compilers may also have issues.
And SMS.

https://superbasic-manual.readthedocs.i ... F/for.html

I totally concur that most of the oddities found have already been unmasked and illustrated in the super SuperBASIC Reference Manual. What I occasionally find lacking is a concise formal description of keyword syntax, rather than having to read through reams of code examples to get the gist of all the quirks, anomalies and variants. This is difficult, I know.

[pjw]

The reason I call the loop example a bug, at least in SuperBASIC/Qlib is that the parser allows something the interpreter later reneges on. If SuperBASIC doesnt like REPeat labels being used as a normal variable, it should fault it. Eg it should complain about line 160, above: if cnt >= loop should cause an Error in Expression. It has the means, because the REPeat label is marked as type $0602 in the Name Table, while the cnt variable is type $0202.

But the fact is that it doesnt really matter! So why make a fuss about it? Thats what MBASIC and SBASIC do, which to my mind is the smarter attitude. Had there been some grand scheme to use labels in some special way that rendered their use as mere variables problematic, well, that would be different..

[pjw]

Heres another loopy bug. This time in SMSQ/E. AFAICS it is not listed in the SBRM: (But dont try this yourself at home!)

Code: Select all

10 x = 1
20 REPeat s$
30  IF x: EXIT s$
40 END REPeat s$

In SMSQ/E V <= 3.34 it causes a privege violation, ie it brings your whole system crashing down over your head!

As of V3.35 it is "fixed", ie, SBASIC, unlike MBASIC, no longer accepts string REPeat labels. This is a cop-out, of course, but I guess its more trouble than its worth to try to really fix it.

I mention this because I know a number of people, for various reasons, dont patch their systems with each new update, and because anyone unfortunate enough to try it could get a lot of grief (as did I!)

[pjw]

I dont know if it works to move this comment from one topic to another, its just that I dont want to clog up the works for Dr Jim:

Sorry (again!) I just couldnt resist this:

Code: Select all

100 x = 1
110 IF x = 0 THEN REMark test
120  PRINT 'SuperBASIC'
130 ELSE
140  PRINT 'SBASIC'
150 END IF

Really, SuperBASIC ought to barf at the ELSE..

This may be accepted by SBasic but does not work when compiled by Qlib 3.36. Then the IF /FOR /REPeat line is seen as inline loop as in QDOS.

BSJR

Actually, I just compiled this with Qlib V3.40 on QPC2. Whether I EXecute the resulting object on SMSQ/E, Minerva or JS it prints 'SBASIC'. If I RUN it on SuperBASIC or MBASIC it prints 'SuperBASIC'. Seems Qlib V3.40 accepts this construct while perhaps V3.36 doesnt.

[NormanDunbar]

What I occasionally find lacking is a concise formal description of keyword syntax...

Hopefully, the top of each command in the Inline Super Basic Manual, has the full syntax for all the commands. Rich did a grand job of documenting them all, and I did a half decent job of converting all the sub/superscripts etc in the online manual.

Cheers,
Norm.

[M68008]

Apart from implementation bugs, the original SuperBASIC was an interpreted rather than compiled language. This makes it legal to use weird syntax.

For example, here is a program to count from 1 to 10 and tell whether each number is even or odd:

Code: Select all

100 DEFine PROCedure even_or_odd(x)
110 IF x MOD 2 == 1:PRINT " odd":ELSE PRINT " even"
121 END FOR i
190 END DEFine never_defined
200 FOR i = 1 TO 10
210 PRINT i;
220 even_or_odd i

It's not a role model of structured programming, but on a JS ROM QL it runs fine and prints:

Code: Select all

1 odd
2 even
3 odd
4 even
5 odd
6 even
7 odd
8 even
9 odd
10 even

[bwinkel67]

As someone who has written interpreters, it's not always convenient to catch every syntactic (or semantic error) especially if done on a resource limited platform (i.e. 128K machine with 90K'ish of free RAM). I know in my ZXSimulator there are cases where something will work that shouldn't. I think presently, for the most part, if you import ZX81 BASIC it runs correctly (unless it's not yet fully implemented like multi-dimensional string arrays, etc...) but there are instances where the interpreter can do "more" and act differently and I'm not inclined to fix it. If someone were to re-implement ZXSimulator from scratch elsewhere then you could have a potential mismatch and that's how oddities are born.

There are also sometimes inconsistencies in the language description itself (i.e. its grammar). I don't recall which language it was (I thought it was Pascal for some reason) but one language used to not have the if/else well defined in its grammar yielding multiple meanings for : if (a>1) if (b > 1) b=1; else a=1

In most languages it's clearly defined in the grammar to be this:

Code: Select all

   if (a>1)
      if (b>1)
         b=1;
      else
         a=1;
 

But in one case the grammar was badly formed and allowed for two interpretations which also included this (leaving it to the language implementer to decide which is not good):

Code: Select all

   if (a>1)
      if (b>1)
         b=1;
   else
      a=1;
 

A well formed grammar isn't hard to write and I haven't seen the malformed one but in BNF, to do the well defined if/else would look something like this:

Code: Select all

<stmt> ::= if ( <cond> ) <stmt> else <stmt>

...or if you only grew up with grammars using tools like lex/yacc or antlr:

Code: Select all

stmt :       'if' '(' cond ')' stmt 'else' stmt ;

[NormanDunbar]

A well formed grammar isn't hard to write ...

I beg to differ, slightly. But then gain, I'm not a compiler writer, nor do I play one on TV.

I dabble with ANTLR4 though.


Cheers,
Norm.

[bwinkel67]

A well formed grammar isn't hard to write ...

I beg to differ, slightly. But then gain, I'm not a compiler writer, nor do I play one on TV.

I dabble with ANTLR4 though.

I suppose my statement was a bit sweeping. For many languages, writing a well-formed grammar is pretty straight forward. For a language like Python it becomes harder since you have to add the idea of tokens to the grammar to account for the variable indentation scheme to show containment. I was focusing on if/else and for that it's pretty easy to write a well-formed grammar...i.e. I'm not sure how, whatever language that messed that up, did so and would love to see its grammar.

[pjw]

Apart from implementation bugs, the original SuperBASIC was an interpreted rather than compiled language. This makes it legal to use weird syntax.

For example, here is a program to count from 1 to 10 and tell whether each number is even or odd:

Code: Select all

100 DEFine PROCedure even_or_odd(x)
110 IF x MOD 2 == 1:PRINT " odd":ELSE PRINT " even"
121 END FOR i
190 END DEFine never_defined
200 FOR i = 1 TO 10
210 PRINT i;
220 even_or_odd i

<>

Made me laugh
Like Amazon's tax returns: Twisted but perfectly legal!
SBASIC, MBASIC and SuperBASIC all swallowed it without a squeak. Turbo wasnt having it, though. It barfed at the "extra END" at line 121, as did QLib.