Re: [lmi] Recursive variables in mustache templates

[Vadim Zeitlin]

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?

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 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.


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.


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 in advance,
VZ

pgpfYvOhfrcV8.pgp
Description: PGP signature