Am 25.08.2018 um 09:44 schrieb Daniel Dekany:
> Any progress? (I understand if not, with a newborn and all, I'm just
> curious.)
Not a lot of progress, but at least I began looking into the first
library last weekend. I'll push my experimental code to github as soon
as it makes sense, so that everyone can have a look at it.
> 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.
Yep, I noticed that part. I've done some manual parsing in the past
(simple top-down LL(k)), but in my limited experience things like good
error reporting and error recovery might be a litte bit easier when
using a parser library which already has decent support for these kind
of things. But it's definitely something to keep in mind as a "plan b".
Stephan.
> 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
>>
>
