Re: LALR parser question

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 30 Apr 2013 04:03:13 +0200, John B. Matthews  
<nospam@nospam.invalid> a écrit:

> In article <op.wwbxyoz9ule2fv@cardamome>,
>  Yannick Duchêne (Hibou57) <yannick_duchene@yahoo.fr> wrote:
>
>> Note: GNAT uses a hand-written parser (I'm pretty sure to remember
>> I've  seen it somewhere).
>
> See also GNAT: The GNU Ada Compiler, §2.2 The Parser, cited here:
>
> <http://stackoverflow.com/a/15544761/230513>
>

While hand‑written parser is not the only worth choice, a good reason for  
this choice is as they say:

“GNU Ada Compiler, §2.2 The Parser”:
> At the architectural level the main subprogram of the
> GNAT parser is an Ada function (Par) that is called to
> analyze each compilation unit. The parser code is organized
> as a set of packages (subunits of the top-level function)
> each of which contains the parsing routines associated with
> one chapter of the Ada Reference Manual [AAR95].

You can't do this with a parser generated automatically from a grammar,  
you can't split the generated parser as it's an automata generated as a  
indivisible whole.

There are still some points I don't agree with…

> Better error messages. GNAT generates clear andprecise error messages
There is a common idiom with automatically generated parsers, to complete  
the grammar so that it include wrong production, which normally does not  
introduce ambiguities, as these are wrong and normally not recognized by  
the grammar. But I agree this is easier with a hand‑written parser.

> Clarity. The GNAT parser follows faithfully the
> grammar given in the Ada Reference Manual [AAR95]
You get the same from an AST produced by an automatically generated  
parser; clarity just happens to be visible more later.

> Performance. The GNAT parser is as fast as any Ada
> table driven parser, and arguably faster than a
> LALR parser.

The main issue with this argument, is that performance isn't a big issue  
at this stage. What comes next — analyses, transformations, code  
generation — is more important for the overall performance of a compiler.  
Then anyway, being exact is far more important than being fast, for a  
compiler, and in that matter, the two previous points values a lot more  
(the points about clarity and precision).



-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University