Interesting BASIC buglet

I thought I would post this because it is the first time I have encountered it in 3 decades of using BASIC.

You cannnot put a REM on the same line after LOCAL DATA or RESTORE DATA.

The reason is clear: when the DATA keyword is tokenised it switches off tokenisation for the rest of the line, and that includes the REM keyword. That means that even with BASIC$Crunch set the REM is not ignored or removed.

No doubt nemo has it on his list. ;-)

Edit. Of course, you cannot put any statement after them, it was just that the REM was what brought it to my attention.

It kind of make senese as you could have in the DATA line REMEMBER etc

Ah! The point is that LOCAL DATA is not a DATA line, but a statement. There is no reason it should not be followed by other statements.

It doesn’t cause any loss of functionality, so in a sense the only bug is that the restriction is not mentioned on the LOCAL DATA and RESTORE DATA pages in the BASIC Guide. But as Steve says, there’s no logical necessity for it and the tiny bit of simplification of the interpreter it allows isn’t worth the risk of weird errors arising if someone unwittingly puts : more statements after DATA. Or at least, it isn’t nowadays; whether it was when BBC BASIC was new I don’t know. But if we fix it in a new interpreter, new code might fail on old interpreters… but it would be nice if the documentation mentioned it, anyway.

I would think that the use of DATA LOCAL is pretty rare these days. I was using it in “an unusual way” and wanted to put a remark to remind me why. It takes a bit of thinking about when the error pops up, so a note in the manual would be useful. I have added it to the StrongHelp one for some future release.

But if we fix it in a new interpreter, new code might fail on old interpreters

A program tokenised by a new interpreter (and distributed as a &FFB file) should run on the old interpreter.

What would fail is if the user were to edit it using the old interpreter.

This may be a distinction without a difference, of course…

But if we fix it in a new interpreter, new code might fail on old interpreters…

Small incompatibilities creep in with various updates – I’m pretty sure I mentioned the issue with compiler / macro features which mean that current source (at least the version where I last tried) doesn’t build a complete ROM unless you have a compiler version newer than v24.

It happens. I wouldn’t even know about that “quirk” if I’d updated my DDE.

new code might fail on old interpreters…

You mean like GCOL r,g,b on machines prior to the RiscPC (or, ahem, ABC)?
Or COLOUR OF x ON y prior to RISC OS 5?

Just two examples that come to mind. ;-)

But as Steve says, there’s no logical necessity for it and the tiny bit of simplification of the interpreter it allows isn’t worth the risk of weird errors arising if someone unwittingly puts : more statements after DATA. Or at least, it isn’t nowadays; whether it was when BBC BASIC was new I don’t know. But if we fix it in a new interpreter, new code might fail on old interpreters… but it would be nice if the documentation mentioned it, anyway.

The issue is in the tokeniser, not the interpreter. I know this, because I remember adding a special case to Tokenize to handle it; the same is applied to REM and EDIT.

The BASIC tokeniser is quite “tight”, and applies a number of “optimisations”, presumably in a quest for speed and compactness. Fiddling with it also has the potential to invoke the law of unintended consequences, as those who worked on BPUT#TRACE would be able to confirm.

That said, I did wonder (on my way back from the pub, so you’ve been warned), whether we could use the fact that the DATA in

DATA 1, 2, 3, 4

is in a “left context”, while the DATA in

LOCAL DATA

is in a “right context” (because LOCAL switches context)? Would it be safe to only apply the “swallow the rest of the line” action if DATA is tokenised in a left context, but carry on as normal when it is encountered on the right hand side?

Is anyone feeling brave? :-)