Rewrite expression parsing and evaluation using expr-parser

zyxw59 commented

2024-02-18 18:56:30 +00:00

(Migrated from github.com)

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)

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 commented

2024-02-18 19:35:40 +00:00

(Migrated from github.com)

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

Hmm, expr-parser does still hard-code some assumptions that don't hold here, namely - there exists a source that `Token`s can borrow from and reference with their `Span`s - the parser takes just the expression and no additional content

zyxw59 commented

2024-02-18 19:46:11 +00:00

(Migrated from github.com)

actually maybe this can be solved with an iterator adapter

zyxw59 commented

2024-02-18 19:53:34 +00:00

(Migrated from github.com)

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.

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 commented

2024-06-29 20:25:00 +00:00

(Migrated from github.com)

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

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 commented

2024-07-03 02:14:02 +00:00

(Migrated from github.com)

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

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

zyxw59 commented

2024-07-03 02:15:40 +00:00

(Migrated from github.com)

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

zyxw59 commented

2024-07-04 01:15:42 +00:00

(Migrated from github.com)

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).

Rows
Columns

Rewrite expression parsing and evaluation using expr-parser #22