|Jack W. Crenshaw - Any clues how to optimize ? firstname.lastname@example.org (XlatB) (1999-04-09)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? email@example.com (Torben Mogensen) (1999-04-18)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? firstname.lastname@example.org (David Whitten) (1999-04-18)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? email@example.com (1999-04-19)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? firstname.lastname@example.org (Bill A.) (1999-04-22)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? email@example.com (Anders Holtsberg) (1999-05-03)|
|Re: Jack W. Crenshaw - Any clues how to optimize ? firstname.lastname@example.org (1999-05-07)|
|Parsing != (either 'recursive descent' or 'operator precedence') email@example.com (1999-05-16)|
|From:||firstname.lastname@example.org (Mike Enright)|
|Date:||7 May 1999 01:14:25 -0400|
|Organization:||CetaSoft (com not cog)|
|References:||99-04-034 99-04-067 99-05-010|
On 3 May 1999 14:44:50 -0400, Anders Holtsberg <email@example.com>
><[Op precedence parsing more economical than rec. descent]>
> (Or am I saying something stupid here: for me "recursive
>decent" and "operator precedance" is mutually exclusive. Correct???)
Not mutually exclusive. I have combined the two (operator precedence
expression parsing within a generally recursive-descent translator).
I'm pretty sure I was just emulating what others did. My one-pass
back-patching byte-code generation was much easier to get right with
operator precedence. With recursive descent it was a pain to have all
the productions doing almost the same things and to revise them when
an optimization came along.
[The original Ritchie C compiler used operator precedence for expressions
and recursive descent for everything else. Worked great, fit in 24K bytes.
Yes, that's a K, not an M. -John]
Return to the
Search the comp.compilers archives again.