Am 13.03.2012 17:24, schrieb Sergiu Ivanov:
Apparently, operator precedence parsing together with some additional
processing of the string may be enough. This may be a good start.
For the umteenth time, NO string processing. You'll be going straight to
ambiguity hell if you do that - you'll end with a parser that misparses
strings just because you weren't careful with the string substitutions.
If you want to substitute, do it on the AST.
For more complicated expressions (like "limit sin(x)/x when x goes to
0"), I think that operator precedence will not be enough.
In fact this kind of stuff is easy. Just make "limit", "when", and "goes
to" bind less tightly than operators.
What's hard is unary minus. Or anything where you want the same symbol
on different precedence levels depending on syntactic context.
> In that
case I'd go for a generator of one of the more powerful parsers (LR
for example).
Did you ever write a nontrivial LR grammar?
Fixing the inevitable shift-reduce conflicts is hard. Really hard.
Fixing the conflicts also means changing the grammar. Which means that
the grammar will produce parse trees that do not reflect the original
grammar anymore.
Adding another rule to an LR grammar tends to break it. All over the
place. Basically, you need to restart the conflict-fixing process.
We'd need an LR grammar expert, or live with the suffering.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
