When exprssions are evaluated, they might throw a ParseError if something fails (e.g. a cooker fails, conversion from string to int fails, etc.). These ParseErrors need to be immediately caught, otherwise the Exception may propagate up too far. We should reexamine all the uses of withParseErrorThrowing, and ensure there all uses of expressions use it as appropriate. We may want to rename it to something like withExpressionThatMayThrow or something to clarify when it should be uses.

Furthermore, one side effect of withParseErrorThrowing is that it allocations an anonymous functions, which does show up in profiling. We should determine if this has a noticeable affect on performance, and if so, think up some other kind of idiom to solve this problem. Perhaps something like Evaluatable's should handle the catch of parse errors, set the state to failed, and then calls to evaluate must check the result, just like we do when calling parser.parse().