|[21 earlier articles]|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-12-09)|
|Re: LL(1) vs LALR(1) parsers email@example.com (Michael Sperber [Mr. Preprocessor]) (1995-12-09)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-12-12)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-12-16)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-12-17)|
|Re: LL(1) vs LALR(1) parsers email@example.com (Scott Stanchfield) (1995-12-18)|
|Re: LL(1) vs LALR(1) parsers G.A.Tijssen@eco.RUG.NL (Gert A. Tijssen) (1995-12-19)|
|From:||"Gert A. Tijssen" <G.A.Tijssen@eco.RUG.NL>|
|Date:||19 Dec 1995 14:24:42 -0500|
|Organization:||Economische Faculteit - RuG|
firstname.lastname@example.org (M.M._van_der_Laan) writes:
>I want to add two ideas to this discussion:
>About quality of error recovery:
>Most errors are NOT detected in the parser, but afterwards. Errors
>detected by the parser are of the kind 'missing something" and in
>those cases there is no need for clever recovery - the program is
>simply wrong, so just skip the statement. Therefore, in my
>opinion error recovery is no argument for selection of the
>right type of grammar.
>For those in favor of handwritten parsers: I also like them
>because they are so easy to understand and fast........
About syntactical error-recovery in the various parsers (hand-written
or automatically generated). I remember that, some 10 years ago, I
saw an automatically generated LL(1) parser for Pascal(generated into
Pascal, easy to read, fast etc.), that has some capabilities that many
(very clever) hand-written parsers don't have.
Consider the following experiment:
Take any correct Pascal program and replace every semicolon (';') by a
space. Then, see what your favourite compiler does with this program.
A good parser will generate the same amount of `` ';' inserted'' error
messages, as the program contained non-redundant semicolons.
Watch and shiver!
I have seen seen compilers, that skip all declarations because the
semicolons are missing, and produce a lot of exotic semantic error
Return to the
Search the comp.compilers archives again.