Since you are going to call these much more often then you parse them, you might want to optimize some expressions using string-eval. Rather than defining a closure that calls another closure for every single step in an expression, you could define a closure that evaluates the expression in-line.
You could optionally define "make a Perl code string" functions for any operations you cared to and then, if all operands have string reps, then you use the "make a Perl code string" instead of the closure. When you get to the end of parsing the statement or to where you have an operation that has no "make a Perl code string" function or a mixture of operands w/ and w/o Perl code strings, then you use $sub= eval "sub { $code }" to get a closure, but a more efficient one.
These "make a Perl code string" functions would look like "*" => sub { "($_[0])*($_[1])" } and Perl's own parser will optimize away most of the extra layers of parens and do constant folding.
- tye
In reply to Re: A parser for a limited grammar (faster)
by tye
in thread A parser for a limited grammar
by clinton
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |