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.)
> 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.)
>>
>
>
--
Thanks,
Daniel Dekany
