I'm just curious if you got somewhere with this. (But it's not like I
hope to be able to dig into this any time soon... I expect to be quite
overloaded in the coming weeks, maybe even for few months. But I
didn't give up in FM3.)
Friday, July 6, 2018, 12:02:41 PM, Daniel Dekany wrote:
> 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
