Re: [lmi] Recursive variables in mustache templates

[Greg Chicares]

On 2019-07-29 15:51, Vadim Zeitlin wrote:
> On Mon, 29 Jul 2019 14:44:23 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I was surprised to learn that mustache has only non-recursive variable
> GC> expansion. Imagine a new language, "mustache2", that is just regular
> GC> mustache, except with recursively-expanded variables.
> 
>  Just to confirm, this really means limitless recursion, not just a single
> level of it, right?

Yes. In practice, one or two extra levels should be enough in most
cases, but some cases may need several levels. Hardcoding a maximum
of one hundred levels in interpolate_string for all recursion is safe.

> GC> To meet business requirements, we need "mustache2" in '.policy' files.
> 
>  Yes, this much is clear, thanks for the motivating examples and
> explanations.
> 
> GC> We must now make two choices:
> GC> 
> GC> (1) Should recursive expansion have a special syntax, like {{=var}},
> GC> much as GNU make has '=' and ':='? I think you favor that, and I'm
> GC> not strongly opposed to it, so let's just choose {{=var}}.
> 
>  The question is whether we're actually going to have any {{var}}s left
> after this change. If we're just going to use {{=var}} everywhere, maybe
> it's not worth introducing it and we should just make {{var}} itself expand
> recursively.

I think we'd have {{var}} everywhere, or almost everywhere, in '.mst'
files, and {{=var}} everywhere in '.policy' files.

>  I also don't especially like "=var" notation, as it's really not obvious
> in which direction it works (i.e. I could expect "=var" to do immediate
> expansion and "var" work recursively just as well as vice versa). I thought
> about using "{{{var}}}" which is much more clear, IMO, but would require
> slightly more changes to the interpolation code. Otherwise, "*var" carries
> the idea of "dereferencing" for C programmers, which is kind of what
> happens with recursive expansion, if you squint enough. But this definitely
> veers into bike-shedding territory by now, so if you like "=var", let's
> just use it.

I don't especially like "=var". All I care about is avoiding the use of
more than one or two extra characters. Clearly alphanumeric characters
wouldn't work. But I'm indifferent among {{=, {{*, {{&, {{<<, and so on,
and {{{}}} is fine with me, too (mustache's specification uses that for
unescaped html, but I don't think we care about that). Feel free to pick
whatever you think is best; if you don't want to choose, then I suggest
[{&var}}. (Or just make all variable expansions recursive.)

> GC> (2) Should we keep these two languages (for short, MST and MST', where
> GC> MST' = MST + {{=var}}) distinct, or just use MST' everywhere? I'd lean
> GC> toward uniformity (only MST', everywhere), but I think you'd rather
> GC> use MST for '.mst' and MST' for '.policy' files.
> 
>  I don't think we can do this. We need to expand "FootnoteNN" in the .mst
> files recursively to make all this work. I.e. it's in the .mst files that
> we must write "{{=FootnoteNN}}" (or "{{{FootnoteNN}}}" or whatever). In
> fact, if anything, we could use MST' in .mst and MST in .policy _if_ single
> level recursion were enough (as it is in your examples). But we definitely
> need to have recursion expansion in .mst.
> 
>  In any case, I don't think there is anything to gain from using separate
> dialects in the 2 cases, as long as we have recursive expansion, there
> doesn't seem to be any reason not to allow it in .policy files as well.
> IOW, I'm fine with doing the same thing for all variables.

Okay, making "{{var}}" always recursive, and offering no non-recursive
variant, is fine with me, too.

> GC> With vacations impending and deadlines looming, we need to find a way
> GC> forward now, and I think we can defer (2) by this expedient:
> GC>  - Start writing {{=var}} in '.policy' files now; and
> GC>  - Implement language MST' everywhere, for now, through a brute-force
> GC>    modification to the existing interpolate_string(), which should be
> GC>    easy enough for me to do myself (call the function recursively,
> GC>    ignoring the '=' in {{=var}}, for example).
> 
>  Yes, basically you just need to copy the handler of "case '>'" in
> do_interpolate_string_in_context() in the "default" case. Also, the error
> message given if the recursion depth is exceeded needs to be adjusted, but
> other than that, I don't see anything else to modify (except for adding the
> tests exercising the new functionality, but this is obvious anyhow).
> 
>  You're, of course, perfectly welcome to do it yourself, but I could still
> do this in the next 2 days, just please let me know if I should do it some
> time soon in this case.
Thanks, it would be great if you could do this.