Open homedirectory opened 6 months ago
After further discussion and an experimental spike it was concluded that the duplication of grammar rules is inherent to any parsing process. At the moment the only general approach seems to be the usage of a generator for the fluent API and the parser so that grammar rules have to be defined only once.
It was decided that it is better to focus on the construction of a formal grammar for EQL and improvements to the existing parser, until the possibility of fluent API and parser generation is better understood.
@homedirectory, can the problems in the existing parser implementation that require improvements be outline?
@01es, yes, and they should be captured in a separate issue. Among them:
caseWhen
used in conjunction with a combination of conditions.
Description
Compilation of EQL expressions involves several phases of analysis and transformation. The focus of this issue is on the first 2 phases: tokenisation and Stage 0 transformation.
The following drawbacks have been identified in the course of work with this approach:
caseWhen
with multiple conditions: it is accepted by the fluent API but rejected during Stage 0 transformation (Phase 2).It is proposed to incorporate Phase 2 into Phase 1, effectively moving syntactic analysis into the implementation of the fluent API. The result of method calls on the fluent API would then be an AST for the EQL expression. Such an implementation would effectively act as an LR parser (with superpowers, due to the ability of semantic analysis).
Expected outcome