|Precedence based parsing Jeffrey.Kenton@comcast.net (Jeff Kenton) (2003-12-03)|
|Re: Precedence based parsing email@example.com (2003-12-08)|
|Re: Precedence based parsing firstname.lastname@example.org (John McEnerney) (2003-12-08)|
|Re: Precedence based parsing email@example.com (2003-12-08)|
|Re: Precedence based parsing firstname.lastname@example.org (Andi Kleen) (2003-12-08)|
|Re: Precedence based parsing email@example.com (2003-12-13)|
|Re: Precedence based parsing firstname.lastname@example.org (Rob Thorpe) (2003-12-13)|
|Re: Precedence based parsing email@example.com (Clint Olsen) (2003-12-20)|
|[4 later articles]|
|From:||firstname.lastname@example.org (Torben Ęgidius Mogensen)|
|Date:||8 Dec 2003 00:17:51 -0500|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||08 Dec 2003 00:17:51 EST|
Jeff Kenton <Jeffrey.Kenton@comcast.net> writes:
> I have been writing parsers and compilers for over 30 years, and one
> technique I have used for parsing expressions seems to have
> disappeared from recent books. It involves comparing the precedence
> of the newest operator with that of the previous operator, in order
> to decide whether to shift or reduce. To me, it seems very
> intuitive, and easy to construct a parser by hand this way (even
> with 17 levels of operator precedence), but none of the new books
> mention it, and some very experienced colleagues have never heard of
> it. Comments? Reasons to prefer other techniques?
Some reasons operator precedence parsing has disappeared from modern
textbooks (it went away between the Aho & Ullman and the Aho, Sethi &
Ullman versions of "The Dragon Book") are:
- It only handles very simple languages.
- It isn't very good at discovering when a string isn't in the
- Operator precedences have been incorporated into LR parsers, so
writing an LR parser for expressions with many precedence levels
isn't very hard.
- Space isn't nearly as much an issue as it used to be.
Return to the
Search the comp.compilers archives again.