[lmi] Recursive variables in mustache templates

[Greg Chicares]

Instead of replying separately to two existing threads that have
come to revolve around a single critical issue, let me start afresh.

Simplified motivating example: where we now have this:
  my_prod.cpp:
      // Product P00 specified in full detail.
    item("ContractName") = "certificate";
    item("Footnote00") = "Read your certificate carefully."
      // ... many other footnotes ...
    item("Footnote98") = "Your certificate is important."
    save("P00.policy");
      // ... many other products ...
      // Product P99 specified in full (massively redundant) detail.
    item("ContractName") = "policy";
    item("Footnote00") = "Read your policy carefully."
      // Respecified in full, but   ^^^^^^ <-- only this word differs.
    item("Footnote98") = "Your policy is important."
      // Likewise:             ^^^^^^ <-- only this word differs.
    save("P99.policy");
and
  M.mst:
    <p>{{Footnote00}}</p>
    <!-- many other footnotes -->
    <p>{{Footnote98}}</p>
    <!-- 99th footnote specified here by historical accident -->
    <p>Another {{ContractName}} footnote.</p>
we want to write this instead:
  my_prod.cpp:
      // global: specified once only
    std::string Footnote00 = "Read your {{ContractName}} carefully.";
    std::string Footnote99 = "Another {{ContractName}} footnote.";
    item("Footnote00") = Footnote00;
    item("Footnote99") = Footnote99;
      // particular to product P01
    item("ContractName") = "certificate";
    save("P01.policy");
      // particular to product P01
    item("ContractName") = "policy";
    save("P99.policy");
and
  M.mst:
    <p>{{Footnote00}}</p>
    <!-- many other footnotes -->
    <p>{{Footnote99}}</p>
where there are already over a hundred different products, which all
have maybe a hundred different footnotes, each of which may be several
hundred characters long. In this example, both ways seem equivalent,
but when the elided 00..99 parts are filled in, the second way is
dramatically terser.

We already have many '.mst' files that use mustache, and it wouldn't
make sense to use a different "little language" for '.policy' files.
We simply want to define these strings economically--as expansions,
which are necessarily recursive--and to move them between these two
types of files (predominantly from '.mst' into '.policy').

We have two issues here: one theoretical, and one practical. The
practical issue is that we must very soon begin to restructure the
proprietary '.policy' files to use recursively-expanded variables.
The theoretical issue is that we haven't yet agreed how best to
implement that.

I was surprised to learn that mustache has only non-recursive variable
expansion. Imagine a new language, "mustache2", that is just regular
mustache, except with recursively-expanded variables. To meet business
requirements, we need "mustache2" in '.policy' files.

We must now make two choices:

(1) Should recursive expansion have a special syntax, like {{=var}},
much as GNU make has '=' and ':='? I think you favor that, and I'm
not strongly opposed to it, so let's just choose {{=var}}.

(2) Should we keep these two languages (for short, MST and MST', where
MST' = MST + {{=var}}) distinct, or just use MST' everywhere? I'd lean
toward uniformity (only MST', everywhere), but I think you'd rather
use MST for '.mst' and MST' for '.policy' files.

With vacations impending and deadlines looming, we need to find a way
forward now, and I think we can defer (2) by this expedient:
 - Start writing {{=var}} in '.policy' files now; and
 - Implement language MST' everywhere, for now, through a brute-force
   modification to the existing interpolate_string(), which should be
   easy enough for me to do myself (call the function recursively,
   ignoring the '=' in {{=var}}, for example).
Later, we can implement {{=var}} properly, and the '.policy' files
that we will have written in the meantime using MST' will already be
correct.