Awhile back, I posted a note about some weird behavior with DATA statements in Color BASIC. The issue was that you really couldn’t have anything else on a line after the DATA keyword other than data.
I recently mentioned this to Alex Evans so he could make sure his BASIC utilities were not combining DATA statements together. He mentioned something to me that demonstrated this issue even more:
100 DATA 1,2,3:PRINT "FOO"
110 DATA -1If you RUN that program, it should print “FOO” and do nothing else, proving that the interpreter does scan the entire line looking for things after a DATA statement.
BUT, if you try to USE that DATA, it will continue reading after the 3 and error out, since the data it finds is not an ASCII number:
Above, the “?SN ERROR” is caused by trying to read a numeric variable from what is NOT a string (the token value for PRINT followed by FOO in quotes). Altering the program to use A$ instead of A (and print one item read per line) shows this a bit better:
Alex explained it like this:
Basically, for the purposes of READ everything after the DATA keyword is part of the data statements, but the interpreter executes the line properly.
– Alex Evans
You can see it appears to treat the colon as a DATA separator, since it does not appear as part of the read DATA.
This is a quirk I do not expect many of us ever encountered, since most of us probable grouped all our DATA together, without mixing commands in with them:
100 DATA 1,2,3,-1I bet all of this was discovered and covered back in the 1980s in various CoCo magazines and newsletters, but the behavior surprised me when I stumbled upon it so I guess I never saw it.
Until next time…
It an interesting behavior which I encountered recently while porting a CBM BASIC program to DECB. I think for most BASIC implementations rooted in Microsoft’s BASIC variant, READ handles DATA as a statement which may terminate either with a colon or end of line.
Looking into the ROM listing shows that DATA itself is skipped as “statement”, not as line (like REM). A PRINT statement in the same line after DATA gets properly executed.
The problem lies in READ itself. Seems to be a bug (or somehow unfinished) to me. Only if the READ variable is of type string a colon is recognized as delimiter. If mixture of DATA with other statements in a line is a thing on might overcome this by using always string variables for READ and convert the values to numbers using VAL(). DATA values do not have to be quoted, even if read as “string”.
TEST
10 DATA 1,2,3:PRINT “FOO”
20 DATA -1
100 READ A:IF A=-1 THEN END ELSE PRINT A:GOTO 100
Another very obscure interpreter bug involving READ/DATA:
10 READ A$: DATA HELLO
20 PRINT A$
With the unnecessary space before the DATA keyword the program fails with ?OD ERROR. Remove the space and it works as expected.