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