Best practice for languages that allow for the dynamic definition of operators

[zmaril]

Does instaparse support creating parsers for languages that can modify themselves? Both Postgres and Haskell allow the language to be expanded to include new infix operators. I don't know how the implementations work in either case, but I was wondering how similar effects could be achieved in instaparse. All I could come up with was recompiling the grammar every time with the addition of the new operator via combinators.

[jeremyheiler]

In this situation, I think I would parse the built-in operators literally, but then define what a legal operator name could be and fall back on that. Then, later on in the compilation or runtime, you can determine if the the operator has been defined.

A parser just needs to get you to what could be a legal program. It doesn't have to do all the work!

[Engelberg]

Instaparse relies heavily on caching to handle recursion, so modifying the grammar along the way would invalidate the cached results. That means any change to the grammar would require restarting the parse fresh from some given point in the string. (If you're using combinators, there's not much of a "compiling" cost to changing the grammar, but you'd have to figure out where to reparse from. Possibly you could do that by using the :total parse mode, and the Failure node is then reparsed with some extended form of the grammar.)

This pull request explored some aspects of this issue: #45

Jeremy's suggestion strikes me as a potentially nice, practical solution.

[zmaril]

Thanks! Thankfully, the question was more out of curiosity than need. I would wonder how those suggestion would work with operator precedence though. I've been using precedence climbing and creating chains of tags that way, with the "cruft" removed later on during transformation. I suppose if that were refactored well enough, it would be possible to insert a new operator in the chain and recompile the grammar that way.