|[2 earlier articles]|
|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:||A Pietu Pohjalainen <email@example.com>|
|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|
Chris F Clark <firstname.lastname@example.org> wrote:
> Detlef Meyer-Eltz <Meyer-Eltz@t-online.de> writes:
>> 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.
> 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).
Return to the
Search the comp.compilers archives again.