|Re: Parsing Expression Grammar firstname.lastname@example.org (Paul Mann) (2005-09-07)|
|Re: Parsing Expression Grammar email@example.com (Paul Mann) (2005-09-11)|
|Re: Parsing Expression Grammar Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2005-09-14)|
|Re: Parsing Expression Grammar firstname.lastname@example.org (Cleo Saulnier) (2005-09-17)|
|Re: Parsing Expression Grammar email@example.com (Sylvain Schmitz) (2005-09-22)|
|generated code Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2005-09-22)|
|Re: generated code cfc@shell01.TheWorld.com (Chris F Clark) (2005-09-23)|
|Re: generated code Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2005-09-25)|
|Re: generated code firstname.lastname@example.org (A Pietu Pohjalainen) (2005-10-13)|
|Re: generated code cfc@shell01.TheWorld.com (Chris F Clark) (2005-10-14)|
|Re: generated code email@example.com (Paul Mann) (2005-10-15)|
|Re: generated code firstname.lastname@example.org (Paul Mann) (2005-10-17)|
|From:||Detlef Meyer-Eltz <Meyer-Eltz@t-online.de>|
|Date:||22 Sep 2005 23:44:12 -0400|
|References:||05-09-023 05-09-045 05-09-058 05-09-071 05-09-094|
|Posted-Date:||22 Sep 2005 23:44:12 EDT|
> Detlef Meyer-Eltz wrote:
> > I am interested to know, how the code for the different
> > would look like. I only know yacc/bison code which for my feeling
> > 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
>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.
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.
Return to the
Search the comp.compilers archives again.