Open zyxw59 opened 8 months ago
Hmm, expr-parser does still hard-code some assumptions that don't hold here, namely
Token
s can borrow from and reference with their Span
sactually maybe this can be solved with an iterator adapter
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.
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
Oh, I'll also need to make expr_parser
able to handle a fallible lexer, since our lexer performs fallible I/O.
Or we could buffer one statement at a time and use that as the basis for the lexer
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).
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)