Re: generated code

A Pietu Pohjalainen <>
13 Oct 2005 20:41:52 -0400

          From comp.compilers

Related articles
[2 earlier articles]
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: A Pietu Pohjalainen <>
Newsgroups: comp.compilers
Date: 13 Oct 2005 20:41:52 -0400
Organization: University of Helsinki
References: 05-09-023 05-09-045 05-09-058 05-09-071 05-09-094 05-09-095 05-09-116
Keywords: design, LL(1)
Posted-Date: 13 Oct 2005 20:41:51 EDT

Chris F Clark <> wrote:
> Detlef Meyer-Eltz <> writes:

>> ---------
>> 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.
> Your thesis is not without merit. In fact, few will argue that table
> driven parsers (either LL or LR ones) are easier to read than
> recursive descent parsers. For most people, your thesis holds true.
> They want to be able to read the parser generator output as a series
> of functions. In fact, the "OO-parsing" that is discussed in another
> thread is just a poor-person's hand-implementation of recursive
> descent, which in some sense proves your thesis.

Yes. This is exactly the point of writing the parser using function
calls: the next guy, who doesn't know about compiler generator tools
wants to have the parser implemented in terms that he already knows;
maybe stepping in the debugger and not wondering why his debugger
opened a strange file with suffix '.y'.

What 'OO-grammars' give to this picture is added clarity: class
structure of the parser reflects the grammar structure. However,
there's no need to restrict possible implementations only to
hand-implemented static code doing function/method/constructor
calls. However, once the implementation moves away from this approach,
its 'steppability' is also reduced.

(Of course, you can always generate beautiful static code, which has
good steppability as well).

Pietu Pohjalainen

Post a followup to this message

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