|Is This Expression Parsing Feasible? Milburn.Young@gmail.com (2007-06-27)|
|Re: Is This Expression Parsing Feasible? email@example.com (Martin Ward) (2007-06-28)|
|Re: Is This Expression Parsing Feasible? firstname.lastname@example.org (2007-06-28)|
|Re: Is This Expression Parsing Feasible? email@example.com (Milburn Young) (2007-06-28)|
|Re: Is This Expression Parsing Feasible? firstname.lastname@example.org (Jeff Kenton) (2007-06-29)|
|Re: Is This Expression Parsing Feasible? email@example.com (Jeff Kenton) (2007-06-30)|
|From:||Jeff Kenton <firstname.lastname@example.org>|
|Date:||Sat, 30 Jun 2007 13:16:58 -0400|
|References:||07-06-066 <email@example.com> 07-06-069|
Milburn Young wrote:
> On 6/28/07, Martin Ward <firstname.lastname@example.org> wrote:
>> On Wednesday 27 Jun 2007 19:37, Milburn.Young@gmail.com wrote:
>>> The parser would scan through the entire list of tokens (left
>>> to right) noting the token(s) with the highest precedence and making
>>> sub-trees out of those tokens
.. . .
>> What about parentheses in the expression?
.. . .
> I see parentheses
> as a (paired) unary operator with the highest of precedences.
Another way to deal with parentheses is to increase the precedence of
each operator according to the nesting of the parens. If you have 20
precedence levels, just add (paren depth) * (highest precedence, i.e.,
20) to each operator's precedence on a first pass. Then remove the
parens and continue according to your original plan.
Another good use for the first pass is to validate the input expression
[How can you validate the input expression syntax without parsing it? -John]
Return to the
Search the comp.compilers archives again.