Am 04.07.2018 um 19:28 schrieb Daniel Dekany:
I wonder what parser libraries could help us, in FM3, to separate the
expression language parsing from the top-level language (like
`<#foo>`, `${...}`, etc.) parsing. Or if a hand written parsers is an
acceptable compromise. It would be good if we can change the top-level
syntax and still reuse the expression syntax. (Or, replace the
expression syntax, and reuse the top-level one.) Like, somebody wants
a syntax like `#foo(exp)` instead of `<#foo exp>`, but still reuse the
expression syntax. (For me it was always part of the FM3 agenda,
though might will be proven to be too much...)
[..]
During the last days I had a high-level look at different parser
generators, and as one might imagine, there are a lot of parser
generators, with different licenses, different maturities, different
states of maintenance and so on.
Due to https://www.apache.org/legal/resolved.html I ignored all parser
generators which may not be included in Apache projects because of their
license, especially GNU GPL etc.
IMHO this leaves us with:
* LL(k) parsers: ANTLR, JavaCC and Grammatica
* LALR parsers: CookCC
* PEG parsers: Mouse
* parser combinators: jparsec, parboiled and PetitParser
This list is not exhaustive, so I probably forget some interesting
projects. If so, please share, I'd like to have a look into these, too.
My idea for the next step: define a really small subset of FTL and try
to implement PoCs for this subset with the candidates which I mentioned
above.
The subset might be something like
* interpolations: ${..}
* directives: if, assign
* expressions: numbers, variables, +
* variants of the parsers with different delimiters
* split into two parsers (interpolations/directives vs. expression language)
What do you think?
Stephan.
P.S.: my more detailed list of parser generators can be found here:
https://gist.github.com/chaquotay/8041096bad36f6f3f0d4166d6f8623b5
