instaparse

If you're not trampolining your parser, why bother getting up in the morning?
2018-04-19T00:00:59.000103Z

we're relying on the greediness of .* to definitely eat the \n even though it`s got a ? on it?

aengelberg 2018-04-19T00:01:41.000386Z

well, . by default means non-newline chars in regex-land

2018-04-19T00:01:47.000004Z

the \n? had me worried that it might parse [" foo" " bar"] from " foo bar"

aengelberg 2018-04-19T00:01:57.000110Z

but yes we are relying on the greediness

2018-04-19T00:02:01.000176Z

👍

aengelberg 2018-04-19T00:02:24.000057Z

#".*(\n|$)" might be safer

aengelberg 2018-04-19T00:03:17.000033Z

btw I believe @dave has some prior art on nested parsers for Alda

aengelberg 2018-04-19T00:03:28.000113Z

actually just kidding I think he migrated away from instaparse in more recent versions of Alda

dave 2018-04-19T01:05:22.000082Z

indeed, i ended up rolling my own parser, mostly in the hope that someday we can start to asynchronously process parsed expressions/statements as they are parsed -- meaning that a score could start playing before it's even done being parsed

dave 2018-04-19T01:05:39.000015Z

...although in doing so, performance got significantly better, to the extent that we might never need to do that 😄

dave 2018-04-19T01:09:08.000226Z

before moving away from instaparse, i was doing some pretty complicated stuff with multiple grammars. it was starting to make my head hurt a little, so that may have had something to do with the decision too

dave 2018-04-19T01:09:53.000182Z

the grammars needed to share some rules with each other, so i was defining grammars using bits and pieces strung together

dave 2018-04-19T01:11:38.000273Z

the reason for that was basically to try and get better perf (without being super knowledgeable about how to improve parser performance otherwise), instead of a big master grammar like i had before, i started parsing out large chunks with more specialized grammars, and do the parsing in multiple passes