Operator precedence

[thelonious]

I noticed this comment in the ragg docs:

ragg doesn’t currently have a good story about operator precedence. Future versions of ragg will support the specification of operator precedence to deal with grammar ambiguity...

I didn't see mention of this in the brag docs. I'm curious if this was addressed. I realize I can define precedence in my grammar's rules, but sometimes that approach negatively effects parse times.

[mbutterick]

The brag story about operator precedence is the same.

brag is basically a front end to cfg-parser, which I use because it handles a wider range of grammars than just parser. Though at the cost of a few features, including operator precedence and debugging (see #19)

In practice, I’ve never found this to be a shortcoming, since you can implement precedence by chaining parser rules (which arguably dovetails more nicely with Racket’s general orientation toward recursive reasoning over imperative reasoning).

That said, I’ve never run an A/B test between cfg-parser and parser to see whether recursion or precedence rules are faster. In general I would expect cfg-parser to be slower primarily because it’s more permissive.

[thelonious]

Thanks for the clarification. Performance is not a requirement for my current experimentation, but its good to know I have options later on down the road, if needed.