Re: Languages with optional spaces and tools

Am 19.02.2020 um 16:35 schrieb Maury Markowitz:


After reading the entire tree, I feel a need for adding my $0.02:


> I'm trying to write a lex/yacc (flex/bison) interpreter for classic BASICs
> like the original DEC/MS, HP/DG etc.


If all you have is a hammer, everything looks like a nail :-(




> 100 FORI = 1 TO 10
>
> The problem is that FORI part. Some BASICs allow variable names with more than
> two characters, so in theory, FORI could be a variable. These BASICs outlaw
> that in their parsers; any string that starts with a keyword exits then, so
> this would always parse as FOR. In lex, FORI is longer than FOR, so it returns
> a variable token called FORI.


Your problem may be the use of lex/yacc! Some older languages are not so
regular and context free and have their own rules for disambiguation.
Such old lexers also can be non-greedy or follow other non-lex rules. So
put aside your hammer and try other tools or your mere fingers...




> [Having written Fortran parsers, not that I've ever found. I did a prepass
> over each statement to figure out whether it was an assignment or something
> else, then the lexing was straightforward if not pretty. -John]


Right, the FORI problem was observed first with FORTRAN, and also was
solved at that time.


When I learned computer science, in the early 70's, the use of parser
generators was almost restricted to the scientific area, for their own
continued development, not for use in compiler construction. At least
the development of a correct formal grammar for those old languages
often; if possible at all; took more time than handcrafting a compiler
front-end.


Also most languages came with a rather informal description of their
terminals, with a more or less complete formal grammar restricted to
their parser.


DoDi

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