> Detlef Meyer-Eltz wrote:> > I am interested to know, how the code for the different> LR-Parsers> > would look like. I only know yacc/bison code which for my feeling> is> > quite awful.

Sylvain Schmitz wrote

> I think it's more a matter of optimized C style than a real problem> on the LR readability.

Cleo Saulnier wrote> First, I think an LR parser generator should always be preferred> over SLR or LALR.

I must apologize that I apparently haven't expressed my question
clearly.

>I wrote : There is a third aspect of the readability: the readability>of the generated code.

This code and especially the integration of semantic actions in this
code is, what I am interested in. That means code for parsers, which
are generated from parser descriptions like yacc. I am interested in
the question, how to do something with a parser.

MY THESIS
---------
is, that recursive descent LL compiler compilers for most purposes
generate the clearest and most flexible code. Parse trees can be
created, but the processed text can be treated directly too.
Descriptions of productions are translated into functions (with
parameters and return types) which directly reflect the description.
Or said the other way round: the descriptions nearly are written like
functions of the corresponding programming language. (In response to
Sylvain Schmitz: As far as I know, Parsec Haskell code cannot be
embedded into other programming languages.)

For some commercial compiler compilers I either haven't found any
online documentation at all or these tools only provide the generation
of some kinds of parse trees or AST's.

There is a discussion appearing again and again in this forum, whether
LL or LR parsers should be preferred. I think, the advantages and
disadvantages are reciprocal. But the one decisive argument in favor
of the LL parsers, generated by recursive descent compiler compilers,
is the simplicity of the code generated by them.