|"Circumfix" operators email@example.com (Joachim Durchholz) (2007-09-07)|
|Re: "Circumfix" operators firstname.lastname@example.org (Jean-Marc Bourguet) (2007-09-10)|
|Re: "Circumfix" operators email@example.com (2007-09-10)|
|Re: "Circumfix" operators firstname.lastname@example.org (Jeff Kenton) (2007-09-11)|
|Re: "Circumfix" operators email@example.com (Joachim Durchholz) (2007-09-13)|
|From:||Jeff Kenton <firstname.lastname@example.org>|
|Date:||Tue, 11 Sep 2007 18:01:57 -0400|
|Posted-Date:||13 Sep 2007 00:59:54 EDT|
Joachim Durchholz wrote:
> I need to read up on ways to extend operator-precedence parsing to
> "circumfix" operators such as (...), [...], if...then...else... etc.
For parens and brackets you want to stack the left one immediately when
you see it and have the matching right one remove it from the stack. I
tend to do this by having a different priority value for operators when
you first see them than when they are on the stack (other ways also
work, of course). I do the same thing with the virtual
start-of-expression and end-of-expression operators.
As for if-then-else, I wouldn't add them to expression parsing unless
they are really valid in expressions, as they were in Algol or are now
in Xpath. Otherwise, I'd use a recursive descent parser for most of the
language and switch to operator precedence parsing just for expressions.
Return to the
Search the comp.compilers archives again.