parser apparently aliases the `state` argument to internal functions

[gwhitney]

OK, inserted return parseSymbol(state) at the point where not is detected. Note that it's necessary to restore state to what it was before grabbing the ( token; you can't just return parseSymbol(saveState). In other words, the state object that comes into parseUnary must be aliased somewhere, so that if it doesn't agree with the state passed into parseSymbol then the parse is spoiled. Should I file an issue about that, or just not worry about it since the parser is working as long as you properly update the input state object in every parseXxx() function? (I'm inclined toward the latter.)

Originally posted by @gwhitney in #3611 (comment)

[gwhitney]

The upshot of the above reference is that although the parser is apparently written to just pass the state from function to function, if you mutate the state (at least within parseUnary) and then pass a different state object to the next function down the line (parseSymbol in this case), some parse tests fail. Presumably what's happening is the state variable in some function higher up the chain holds a reference to the one being passed down, and relying on that specific object to have the proper contents once control comes back up to it. In that scenario, mutating the state that comes in and then deciding to throw that state away and proceed with a different one could indeed disrupt the parse.

There are a few ways we might address this:

1. Hunt down and eliminate all such instances of aliasing the state object
2. When you make a clone to try a subparse, always be sure to pass the clone down and then if the subparse turns out to succeed, only then update the state that came into the current level.
3. Stop passing the state from function to function and instead make it a shared variable among all the parse functions.

I feel like solution (3) would be the most difficult to read/least maintainable option