Operator precedence #22

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.

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.

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.

The `brag` story about operator precedence is the same. `brag` is basically a front end to [`cfg-parser`](https://docs.racket-lang.org/br-parser-tools/Context-Free_Parsers.html?q=cfg-parser#%28form._%28%28lib._br-parser-tools%2Fcfg-parser..rkt%29._cfg-parser%29%29), which I use because it handles a wider range of grammars than just [`parser`](https://docs.racket-lang.org/br-parser-tools/LALR_1__Parsers.html?q=cfg-parser#%28form._%28%28lib._br-parser-tools%2Fyacc..rkt%29._parser%29%29). 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](https://beautifulracket.com/basic-2/expressions.html#parsing-with-order-and-precedence) (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.

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.

Labels Milestones

Operator precedence #22