Friday, July 6, 2018, 10:57:59 AM, Stephan Müller wrote:
> 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.
If you are interested, then just give it a try! I mean, obviously, you
won't take anyone's job position, so it's not a "candidate" thing, nor
you have to make any promises.
I think no much FM specific knowledge is needed for this. But if
there's anything, I will be here to clarify things.
> 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.)
>>>>
>>>
>>>
>>
>
>
--
Thanks,
Daniel Dekany
