Interpreter - an entirely different kind of animal. Microsoft didn't get a BASIC compiler until much later.
> He helped Wozniak implement a version of BASIC supporting floating point numbers.
No. He sold Apple a BASIC, then used it as leverage to prevent Apple from making a BASIC for the Macintosh.
> Ballmer was the biggest businessman in the bunch.
He suggested cutting Paul Allen's family off when Allen was battling cancer.
D's compile time function execution engine works that way. So does the Javascript compiler/interpreter engine I wrote years ago, and the Java compiler I wrote eons ago.
The purpose to going all the way to generating machine code is the result often runs 10x faster.
Um, no? your experience is probably at least two decades after the time period in question.. The more advanced versions of, for example, the TRS-80 BASIC (part of this "microcomputer BASICs that all share a common set of bugs") did no more than tokenize - so, `10 PRINT "Hello"` would have a binary representation for the line number, a single byte token for PRINT, then " H E L L O " and an end-of-line marker. Actually interpreting the code involved just reading it linearly; GOTO linenumber involved scanning the entire code in memory for that line number (and yes, people really did optimize things by putting GOTO and GOSUB targets earlier in the program so the interpreter would find them faster :-)
It's a VM of a sort, and the p-code the VM executes is tokenized input.
The BASIC interpreter doesn't recognize `3+x*(2+y)` nor does it compile it instead it evaluates that expression using a pair of stacks. You've expanded the definition of compilation to cover almost all computation. It's compilers all the way down to the electrons.
Many programming languages parse their program to an AST then walk that AST interpretting as they go. But for BASIC you can parse/execute statement by statement - no need to parse the whole program ahead of time, and certainly zero need to compile to either machine code or any internal representation.
Remember at the time we're talking about 64k was a lot of RAM. Some machines had less.
I.e. the basic program was lexing and parsing. It's a compiler. A very simple one, sure, but a compiler.
"Nobody" uses it that way, and language is defined by use.
You of all people should know this, come on.
But 99.9% of people take "compiler" to mean translating source code to either a native CPU instruction set or a VM instruction set. In any tutorial on compilers, tokenization is only one aspect of compilation, as you know very well. And unlike some of the tricky tokenization aspects that crop up in languages like C++, BASIC interpreters simply had a table of keywords with the MSB set to indicate boundaries between keywords. The tokenizer simply did greedy "first token which matches the next few characters" is the winner, and encoded the Nth entry from that table as token (0x80 + N).
When LIST'ing a program, the same table was used: if the byte was >= 0x80, then the first N-1 keywords in the table were skipped over and the next one was printed out.
There were also BASIC implementations that did not tokenize anything; every byte was simply interpreted on every execution of the line. There were tiny BASICs where instead of using the full keyword "PR" meant "PRINT", and "GO" meant "GOTO" etc.
This was used to save memory -- there wasn't much room to hold both the source code and an intermediate form. But also it wasn't that necessary, with the keywords tokenized and the syntax so simple that there wouldn't have been much savings in space or performance.