Am 06.07.2018 um 10:30 schrieb Daniel Dekany:
> Friday, July 6, 2018, 8:44:39 AM, Jacques Le Roux wrote:
>
>> Hi Daniel,
>>
>> Maybe we could find someone interested in the context of GSCOC. But it's
>> perhaps a bit late already?
>
> Are such a thing "GSOC worthy" at all? Never though of that. Anyway,
> to be clear, it's mostly just research, not much coding. I thought
> someone may be interested. (I am, but obviously I want other to be
> active as well.)
>
I'm kind of interested, but I haven't done any FM- and parsing-related
stuff lately, so I'm probably not the best candidate.
Stephan.
>> Jacques
>>
>>
>> Le 04/07/2018 à 19:28, Daniel Dekany a écrit :
>>> 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...)
>>>
>>> While the next item in the FM3 pipeline supposed to be
>>> https://issues.apache.org/jira/browse/FREEMARKER-99 (uniform top-level
>>> syntax, and part of the Dialects feature), maybe this parser
>>> combinator thing changes what parser library we should built upon, in
>>> which case first implementing FREEMARKER-99 on top of JavaCC can be
>>> wasteful (OTOH that can be done right now at least).
>>>
>>> So, anybody would enjoy doin a bit of research in this area? Like
>>> recommend a solution, with some minimal proof-of-concept? (Mind you,
>>> FM is kind of sensitive to parsing speed; not all applications can use
>>> caching aggressively, like some might use ?eval and ?interpret quite
>>> much. Also, being able to combine parsers on runtime is nice but not a
>>> requirement. But being able to generate a combined parser at least on
>>> build time is certainly needed.)
>>>
>>
>>
>
