Not yet, because my son was born last week, so my priorities were
elsewhere ;-)
But it's still on my agenda. I hope to find time for it in the next days.
Stephan.
Am 23.07.2018 um 09:15 schrieb Daniel Dekany:
> 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.)
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
