Compiled path test suite #102
Conversation
…tion signatures. Updated the grammar to handle function expressions more explicitly and aligned them with RFC standards for LogicalType, NodesType, and ValueType.
There was a problem hiding this comment.
During the course of testing functions I've realized that the current grammar isn't enforcing well typed arguments, meaning that a function call could make it through the grammar but still be considered invalid. This would seriously hamper the notion of being able compile paths because they would pest parse correctly then need to be checked again. I think tightening the grammar further to include a notion of the 3 types mentioned in the RFC would allow for a much more concise parser, as well as reduce validation logic during path parsing.
There was a problem hiding this comment.
I've read the RFC like 4 times now, and though I think I've got everything, but my head is starting to spin.
|
I've specifically been putting a lot of focus into 2.4.2-3 and the examples laid out in 2.4.9. To me this feels like one of the last things to add to the grammar in order for the pest parser to generate completely valid paths. I also think that the closer the grammar is to being fully comprehensive the better off we are in terms of extensibility and safety. Currently I left every little piece of info in the grammar file as comments and tried to mostly not change the parse tree that's being output so that we can make minimal code changes at first and then incrementally change the code to better fit the parse tree once I get all tests passing. Other than that I need to perform similar changes on both versions of the AST then clean up a bit and this PR will be ready. |
Still a work in progress but was hoping for feedback