|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 email@example.com (A Pietu Pohjalainen) (2005-10-13)|
|Re: generated code cfc@shell01.TheWorld.com (Chris F Clark) (2005-10-14)|
|Re: generated code firstname.lastname@example.org (Paul Mann) (2005-10-15)|
|Re: generated code email@example.com (Paul Mann) (2005-10-17)|
|From:||"Paul Mann" <firstname.lastname@example.org>|
|Date:||15 Oct 2005 13:00:47 -0400|
|Posted-Date:||15 Oct 2005 13:00:47 EDT|
"Chris F Clark" wrote ...
> I have nothing against recursive descent as an implementation
> technique as the output of a tool (other than it can lead to the
> acceptance of hand-written recursive descent compilers). Hoever, I
> think it is irresponsible to recommend hand-writing recursive
> descent parsers. It leads to shoddy programming.
> [If you hadn't said it, I would. Writing code to make it easy for
> people who don't understand it to make arbitrary changes does not
> strike me as a winning strategy. -John]
Thanks Chris and John !
I look forward to the day when we view recursive-descent hand-written
code as we view hand-written applications in assembly language.
Also, doing research with error recovery, partial parsing, and other
things is virtually impossible with hand-written recursive descent
When I first discovered table-driven parsers I was relieved to know
that there was something I could depend on to be free of errors.
Finally, something in computer "science" that has a hint of
engineering associated with it.
Return to the
Search the comp.compilers archives again.