Carlyle-Foster
Carlyle-Foster
i've made a lot of progress on this in a branch, got ```()``` and ```[]``` and ```/``` down, but i'm starting to reconsider the approach of having different formats when...
can't multiple `Term -> [Expression]`'s just be combined into one? it seems semantically equivalent
couldn't we just do what we're doing now, using the normalized version for parsing but not exposing it to the user? if they give us `s = a / b...
though know that i say that i realize it makes decomposing productions the same way u might compose them impossible
not sure if that's a compelling enough use case though, u can still decompose productions easily enough so long as they're normalized in the first place
i don't like this parser API because it implies that if u just want to analyze grammars then the ```Grammar``` struct will suffice, but ```Grammar```'s are too raw to be...
we also need the "parser" info to validate Grammars ala #136, which strongly suggests it's useful for more than just parsing
i think that we should definitely support grammars that operate on unicode, but for the grammar definitions themselves limiting unicode support to terminals could be an avenue for performance gains...
it's not a pressing issue though, rn i think we handle unicode correctly and use it everywhere
i don't think we'd have to look for ```;``` all the time, unless there's some de facto standard for for closing comments within a line comments can never appear as...