Any progress? (I understand if not, with a newborn and all, I'm just
curious.)
Note my answer to Angelo. As I said there, maybe we should settle with
only expression parsing done by the parser library, and the others are
done "manually". While that removes most of the tricky requirements
from the parser library, it brings in a new one, that doing many
independent expression parsings should have minimal overhead.
Sunday, August 5, 2018, 6:58:11 PM, Stephan Müller wrote:
> 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
>
--
Thanks,
Daniel Dekany
