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.html#v:buildExpressionParser

with a table similar to
https://hackage.haskell.org/package/haskell-src-exts-1.23.0/docs/Language-Haskell-Exts-Fixity.html#v:preludeFixities

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.