generated code

Detlef Meyer-Eltz <>
22 Sep 2005 23:44:12 -0400

          From comp.compilers

Related articles
Re: Parsing Expression Grammar (Paul Mann) (2005-09-07)
Re: Parsing Expression Grammar (Paul Mann) (2005-09-11)
Re: Parsing Expression Grammar (Detlef Meyer-Eltz) (2005-09-14)
Re: Parsing Expression Grammar (Cleo Saulnier) (2005-09-17)
Re: Parsing Expression Grammar (Sylvain Schmitz) (2005-09-22)
generated code (Detlef Meyer-Eltz) (2005-09-22)
Re: generated code (Chris F Clark) (2005-09-23)
Re: generated code (Detlef Meyer-Eltz) (2005-09-25)
Re: generated code (A Pietu Pohjalainen) (2005-10-13)
Re: generated code (Chris F Clark) (2005-10-14)
Re: generated code (Paul Mann) (2005-10-15)
Re: generated code (Paul Mann) (2005-10-17)
| List of all articles for this month |

From: Detlef Meyer-Eltz <>
Newsgroups: comp.compilers
Date: 22 Sep 2005 23:44:12 -0400
Organization: Compilers Central
References: 05-09-023 05-09-045 05-09-058 05-09-071 05-09-094
Keywords: parse
Posted-Date: 22 Sep 2005 23:44:12 EDT

> 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

>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.


Detlef Meyer-Eltz



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.