Someone uploaded the K&K book “Back To BASIC: The History, Corruption, and Future of the Language” to Internet Archive. It’s a slightly ranty book about how everyone else did BASIC wrong. It’s quite amusing in places.
(via)
5 Likes
I have to give them credit for recognizing that line numbers were a mistake. But like their other reasonable complaints about BASIC on microcomputers it seems like it was a necessary compromise. At least, based what I assume was fairly primitive file editing capabilities on minicomputers at the time.
They do seem to underestimate the difficulties of running BASIC on earlier microcomputers. It’s not just limited memory. Many useful systems didn’t even have a floppy drive and even ones that did aren’t making a compiled version very attractive. I feel like until you have a hard drive a compiler is rather onerous.
They make a good point about how FOR loops shouldn’t execute if the initial value is already past the end value. But once you’re interpreting BASIC I don’t see any sensible way around that because the NEXT statement has no association with the FOR loop. Feels like you’d have to solve the halting problem in order to make it work.
Now that I think of it, their complaints about errors only being reported when code executes and some other things boil down to interpreter vs. compiler.
Interesting stuff to read; thanks for pointing it out.
1 Like
I hear that argument a lot, but I don’t understand it. Many BASIC interpreters manage it just fine. The ECMA-55 standard (page 18) shows how it should be done.
1 Like
Ah, I see. They make a rule to force the association of a particular NEXT statement with a FOR loop which comes naturally as result of parsing the entire program. So, yes, doing a pass over the program before running to match up FOR and NEXT would be enough for an interpreter.
The reason I invoked the halting problem is that all the early microcomputer BASIC interpreters do no such thing. They simply execute a statement at a time and simply keep a stack of FOR statements that are active and act appropriately when they see a NEXT. In fact, they break several rules in the standard you referenced. They allow NEXT without a control variable. Or a NEXT with a control variable that is not the current one. Which means it walks down the stack until it finds a FOR with a matching control variable.
But even their lack of one-to-one association with FOR and NEXT will lead to some touch questions to answer. For instance, what should the output of this be:
10 FOR I=1 TO 0
20 INPUT G:PRINT G
30 IF G=1 THEN NEXT G:END
40 NEXT G:PRINT"DONE":END
The rules would say the loop shouldn’t execute but which NEXT should it skip to?
This kind of thing (and worse) is why someone might think the problem isn’t solvable. When, of course, it is solvable but not without changing the existing microcomputer BASIC interpreters. With their forgiving rules there’s just no way to enforce skipping the first iteration.
1 Like
None of them. Errors out with Unexpected NEXT in line 30. I couldn’t get any interpreter to make sense of it, not even Commodore BASIC.
Sinclair BASIC (not the ZX80 version, but the ZX81 and Spectrum version), Locomotive BASIC (Z80) and BASIC-80 v5.21 (8080) somehow manage just fine.
Interesting… I see Spectrum Basic has an error code
I FOR without NEXT : There was a FOR loop to be executed no times (e.g. FOR n= 1 TO 0) and the corresponding NEXT statement could not be found
I suppose it must scan forward from the FOR. What is it looking for? Any NEXT token, perhaps guarded by an IF? Or any NEXT token which is the first on a line? (Multi-statement lines, and IF which is not GOTO, are possibly outside the standard?)
Terrible typo in the code. I meant to write NEXT I. I tried this in TRS-80 Model 1, Level II BASIC:
10 FOR I=1 TO 0
20 INPUT G:PRINT G
30 IF G=1 THEN NEXT I:END
40 NEXT I:PRINT"DONE":END
It will input G and echo it back. If you enter 1 then the program ends. Otherwise it’ll print DONE and then end.
I’ve not tested it, but I’d imagine it’d be the same result with any of the early Microsoft BASICs like PET or Apple ][
1 Like
Yes, it will do that in any of Microsoft’s “street BASIC” 6502 implementations. It will also do it in BBC BASIC. But in the BASIC I grew up with (Locomotive BASIC on the Amstrad CPC), it will exit immediately. It will not print anything. Running with TRON only shows it hits line 10. Same with later BASIC-80 versions for CP/M.
Interesting. I tried on CPC-box, and it looks like the FOR causes a textual search for NEXT and we find the END on line 30:
Atari 800 BASIC does run the loop once. I wanted to try it since, as far as I know, it was an independent implementation that has nothing to do with Microsoft.
4 Likes
Since multi-statement conditional program flow is implementation-specific, you’re going to get many possible results from many different interpreters. Of the ones that support multi-statement lines, that is.
This is not a good use of a FOR loop. You don’t know if it’s going to run, or what it’s going to do after.
It does get a little ranty and uppity but I think K&K can be forgiven in this regard, it was their baby after all. (I have the book, support used book stores, consider them a distributed backup replica.)
4 Likes
It was possible to compile Basic programs with a floppy drive. I did it with an Apple IIe, and have done it with an Atari 8-bit. It does require what was then a full memory configuration, like 48K or 64K. Both compiled off of tokenized files. The time I did it on the IIe, I used two drives, using the Einstein Basic compiler, and I needed both of them.
I’ve compiled programs using Turbo Basic XL on the Atari 8-bit. It came with an interpreter and a compiler. The compiler compiled to RAM. Once compiled, the program was saved to a binary file. Though, I think the compiler took a lot of shortcuts to conserve memory, which made it rather unreliable. I often found that it would stop with “no errors,” but when I tried to run the binary file, it would either stop with an error, or just crash, despite the fact that the interpreted version ran fine.
I recently researched what happened with Basic on the Atari ST, and heard about True Basic, written by Kemeny and Kurtz. They made versions for all of the 16-bit platforms. I read a review of it in an ST magazine, and while they said it ran reliably, and was a nice environment to work in, they also said it was slow, leading them to think not many would like that.
What I saw at the time was most ST users that wanted Basic used GFA Basic from GFA Software, since ST Basic from Atari was horrid, at first. It had a ton of bugs that Atari eventually fixed. Even so, the way it did things in GEM rubbed a lot of people the wrong way.
1 Like
A couple of things I noted in the parts I read: they keep the LET keyword - I had associated this with making it easy for small microcomputer interpreters. And they seem to have pass-by-reference parameters. I didn’t see this explicitly, but their swap subroutine depends on it.
Yeah, I had True Basic on the Amiga.
GFA Basic was really good, but threw out GEM altogether. It enforced Dartmouth/True Basic’s one statement per line, but took it to the extreme. It didn’t allow blank lines, replacing them with !, GFA’s comment character.
FAST Basic on the ST was particularly nice. An interpreter with full GEM integration and a particularly nice dialect of BBC BASIC. It was the “teach the 1st year engineers programming” platform for me at University of Strathclyde.
That seems a worthwhile thing - I think the 8 bit BBC Basics lack it but the later ones have it.
I get what you’re saying, since the editor did away with the GEM UI, but what I’m reading is it was possible to program for GEM in it, maybe with external libraries. The examples I’ve seen so far are in VDI, though.
A little late to the party, but I had an Atari 800, and the first thing I’d say if I saw this is, “You forgot to add ‘STEP -1’ to the end of line 10!” 