Re: Languages with optional spaces

On Wednesday, February 19, 2020 at 8:24:02 AM UTC-8, Maury Markowitz wrote:
> I'm trying to write a lex/yacc (flex/bison) interpreter for classic BASICs
> like the original DEC/MS, HP/DG etc.


> I have it mostly working for a good chunk
> of 101 BASIC Games (DEF FN is the last feature to add).


> Then I got to Super Star Trek. To save memory, SST removes most spaces, so
> lines look like this:


> 100FORI=1TO10


The first BASIC systems I ever used were the HP TSB2000 systems
that were very popular in the 1970's. These systems tokenize each
line on entry, and also syntax check it. If a line fails, it isn't
even stored. Extra spaces or none, the line is stored the same way.
(And this is the system that many of the original Star Trek games
were written on.) Also, numeric constants are converted to their
internal representation. The LIST command converts the tokenized form
back to text form, and adds appropriate blank space.


Note also that the TSB2000 systems only allow the traditional
single letter, or number-digit, form for variable names.


The microcomputer BASIC systems that I remember tokenize lines, but
don't do any more checking on them. As noted, blanks are stored and
used when the LIST command displays the program.


Looking at the GW-BASIC manual:


http://www.divonasperi.it/divona/tam/tecnologia/dow-all/GW%20Basic%20(inglese).pdf


and the PC-BASIC manual:


https://robhagemans.github.io/pcbasic/doc/1.2/#memory


(the latter intended to be bug-for-bug compatible with the MS version.)


I don't see in either manual mention of the effects, or lack thereof,
of blanks in statements. There is explanation of reserved words,
and their possible use in variable names. It seems to me that
the treatment of missing blanks is an accident of the parser design.


Bug-for-bug emulation, then, needs to find all those accidents
and implement them.

Return to the comp.compilers page.
Search the comp.compilers archives again.