Rewrite expression parsing and evaluation using expr-parser

[zyxw59]

https://github.com/zyxw59/expr-parser It's now ready for use, and should let us simplify the parser code and potentially evaluation code (relevant for #18)

[zyxw59]

Hmm, expr-parser does still hard-code some assumptions that don't hold here, namely

• there exists a source that Tokens can borrow from and reference with their Spans
• the parser takes just the expression and no additional content

[zyxw59]

actually maybe this can be solved with an iterator adapter

[zyxw59]

except we still need a way to detect parens that doesn't conflict with parens that might exist within an expression, for parsing things like the points from syntax. Or maybe we should add capability to expr-parser to do something like "start with a delimiter on the stack and return once its matching delimiter has been parsed". Alternatively, we could change the syntax of points from (and others with similar constraints) to use a delimiter not used by expressions.

[zyxw59]

hmm, we could just include the open paren at the start. there' still the issue of knowing when to stop though. maybe the parser just needs an option to say, "parse one term and then stop", which would just add a check after each call to parse_next that would break if the stack is empty

[zyxw59]

Oh, I'll also need to make expr_parser able to handle a fallible lexer, since our lexer performs fallible I/O.

[zyxw59]

Or we could buffer one statement at a time and use that as the basis for the lexer

[zyxw59]

Oh wait, the canonical way to handle errors in lexing is to just pass them as their own tokens that the parser decides what to do with (raising an error, presumably).