|Lemon, fallback, and vacuous tokens. email@example.com (qarnos) (2011-01-02)|
|Re: Lemon, fallback, and vacuous tokens. firstname.lastname@example.org (glen herrmannsfeldt) (2011-01-03)|
|Re: Lemon, fallback, and vacuous tokens. email@example.com (2011-01-05)|
|Re: Lemon, fallback, and vacuous tokens. cfc@shell01.TheWorld.com (Chris F Clark) (2011-01-14)|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||Mon, 3 Jan 2011 05:05:41 +0000 (UTC)|
|Organization:||A noiseless patient Spider|
|Posted-Date:||04 Jan 2011 11:21:17 EST|
qarnos <email@example.com> wrote:
> If you are not familiar with fallback tokens, the idea is fairly
> simple: The grammar specification can define an input symbol as being
> a "fallback" for another input symbol if the parse should fail. If I
> declare "IDENTIFIER" to be a fallback for "KEYWORD", and a construct
> can not be parsed using "KEYWORD", Lemon will substitute "IDENTIFIER"
> and re-try the parse before throwing an error.
> This got me thinking about a method for handling common error cases,
> such as missing semi-colons in a C program, without sprinkling
> "error" tokens throughout the grammar, which I find incredibly
> tedious. Why can programmers just not make mistakes!
The OS/360 PL/I (F) compilers has many diagnostics similar to:
"MISSING SEMICOLON, ONE INSERTED"
(the compiler only knows upper case)
in which case it inserts one into the internal data structures
(not the input source) and continues parsing.
In the days where it might have been hours between job submission and
seeing the results, it helped that the compiler could find as many
errors as possible in one run.
I do remember running with the JCL options to link and execute even
with compilation errors, though that may not have been usual.
Now, most people will look at the first message, fix the error, and
then recompile without even looking to see if there are more to be
Return to the
Search the comp.compilers archives again.