Evaluate expressions sequentially

[jkeiser]

Currently we evaluate expressions by recursively going up a tree. With , we had to make that work.

Switch to evaluating expressions in lexical order, since that's what we do. 1+(2*3)+4 means evaluating in this order: 1, + (2*3), + 4. (2*3), being a group, is recursively evaluated. This limits recursion to expressions that require it.

Pros:

• This would allow us to store way less information in the ast--just the extra groupings given to us by precedence and spaces.
• It also means a much more linear traversal since you don't start somewhere in the middle of the ast, so more will be in cache.

Cons:

• It ... might? make it harder to actually build the tree, if we're using that data while we build it. I'm pretty sure it won't make it any harder to traverse (it should be easier).

Notes:

• The ; = and : operators have a high tendency to create precedence groups, which necessarily cause recursion that might not be necessary. (, needs the recursion for sure.) Not exactly a con--we're recursing right now so this won't make it worse.
• You could actually execute code while it is being parsed (use case? Maybe maybe not.).
• There is an operator extensibility story there that might let us build ?:, if, and , as standard operators instead of treating them special in the evaluator as we do now. Might even be possible with { and (, not sure about that one.
• It's possible (though not sure if desired) to forego precedence groups altogether and end up with a cleaner tree that represents the actual syntax more closely. Doing this might actually allow operators to have different precedence in different situations, if that's needed or desired.