related:

symbol = #'(?!(->|=)\\b)[+/*<>:&|=^?%#~!-]+'

oh awesome, let me try that now

I had meant to circle back and fix all that stuff on the bottom...

@aengelberg yeah, that's pretty awesome. Thanks a ton. I guess I have some work to do

Its cut nearly in half on JS

just curious, does Elm allow newlines pretty much anywhere there can be whitespace? if so, I would recommend making a universal ws and ows (optional whitespace) that allows whitespace, newlines, and comments, which you can then spam in your grammar anytime you would use <break>.

whitespace and comments are sometimes the trickiest parts of grammar perf

Its pretty flexible with newlines yeah. It does care about indentation (which I haven't attempted to model in anyway). Are you saying that break performs poorly or that it would be easier to maintain if I just settled on fewer whitespace tokens

I don't think anything's wrong with break, but you might run into false negatives i.e. valid Elm code that doesn't parse properly

and making ws easier to reason about makes you less likely to fall into ambiguity traps like two adjacent ws parsers

yeah that's a good point

break probably can go. It was just the result of trial and error when I first picked up the parser, I shouldn't feel particularly attached to it if I can just use ws everywhere

thanks again. This is far more support than I expected

No problem

I think it might also make sense for me to roll comments into a rule similar to that

they too can appear anywhere

Agreed. Your usage of single line comments seemed kind of arbitrary though admittedly I'm not familiar with Elm

yeah its totally arbitrary. I've punted on all inline comments atm

the only challenge was modeling them in a meaningful way. I wanted to be able to convert the tree back into code and preserve the comments, or be able to include data about comments in queries against the parse tree