You can cheaply reduce the cost of some of it by combining operators with the same precedence and associativity. For instance, instead of doing as the example says and having separate table entries for "+" and "-", have one entry that parses a "+" or "-" and returns the appropriate operator. On Sat, May 2, 2020, 10:44 Johannes Waldmann < johannes.waldmann@htwk-leipzig.de> wrote:
Dear Cafe,
I use `buildExpressionParser`
https://hackage.haskell.org/package/parsec-3.1.14.0/docs/Text-Parsec-Expr.ht...
with a table similar to
https://hackage.haskell.org/package/haskell-src-exts-1.23.0/docs/Language-Ha...
and I find it's somewhat expensive. I think the algorithm makes me pay for each operator that is in the table even when just a few of them are actually in the input. (I removed from the table those that don't appear in my test cases, and it got faster.)
Certainly this is known? What could be done about it? What does Megaparsec do? It seems that Text.Megaparsec.Expr vanished from version 6 to version 7.
A classical shift/reduce algorithm would help (?) but not with the given type of table, which does not allow to parse an operator just once, and then look up its precedence.
- J.W. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.