Monday, August 27, 2018, 10:22:31 AM, Stephan Müller wrote:
>
> 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.
Great, looking forward to see the outcome!
>> 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".
I see this "plan b" as a quite likely outcome, so I won't be shocked.
But we will see anyway.
Some musings...
Our current JavaCC solution has quite unhelpful error reporting when
it comes to the JavaCC-generated part of the error messages. Basically
it just dumps the tokens it has expected at the user, which I think is
rarely helpful for the average user, and is scary... That's maybe
nearly as much as can be automatically generated, but my point is that
we could get by without that feature, which is good, because that part
is impractical to implement in a hand written parser that I can
imagine. Surely JavaCC also tracks the positions for you, which is
obviously needed for useful error messages, but I belive that part is
not a that big deal to do manually.
Another thing that's the current JavaCC parser does poorly is
reporting tag pairing problems. We tried to hack some error post
processing on top of it, which tells which tag you have forgotten, but
it's ugly, and doesn't work reliably. But as I said much earlier, this
type of problem raises to a new level with FM3's dialects feature.
Doable even in JavaCC, but on the cost of losing some of the elegance
why you use a parser generator on the first place.
BTW, another variation is when you use a lexer generator, but not a
parser generator...
> 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
>>>
>>
>
>
--
Thanks,
Daniel Dekany
