Re: RFC: String interpolation

[Ted Zlatanov]

On Fri, 9 Dec 2016 17:45:16 -0500 Clément Pit--Claudel <address@hidden> wrote: 

CP> On 2016-12-09 14:19, Ted Zlatanov wrote:
>> On Wed, 7 Dec 2016 20:13:41 -0500 Clément Pit--Claudel <address@hidden> 
>> wrote: 
>> I'd rather see either something like Mustache templates or simply using
>> the format-spec.el that comes with Emacs. The advantage in my opinion
>> (informed by many years of using Perl, where string interpolation is a
>> way of life) is that clarity is improved by separating the format spec
>> from the data that fills it out, and it's very tempting to stuff logic
>> into strings but maintenance is unpleasant.

CP> Thanks for the feedback! Can you share concrete examples in which
CP> this makes maintenance harder?

Just imagine *any* Perl code "@{[ inside here ]}" and you're ready.
Things like embedded hash slices, in-place sorts or Schwarzian
transforms...

    (let ((a 12) (b 15))
      (format-spec "%a + %b = %u" (format-spec-make ?a a
                                                    ?b b
                                                    ?u (+ a b)))

CP> Thanks. Are there benefits of this over just (format "%s + %s = %s" a b (+ a
CP> b))? The names ?a and ?b seem redundant, and ?u doesn't carry specific 
meaning.

Yes, of course. It's the same as positional vs. named arguments to
functions. In (format "%s %s %s" x y z) you have to remember each
parameter, and if you want to repeat x twice you have to write it two
times.

To take a step back, imagine a spectrum. At one end is (format "%s %s
%s" ...) which is fast, easy to implement, familiar to those who know
sprintf, and anonymizes the template data, filtering it through a type
expression. This is extremely popular and is not going away.

The middle of the spectrum are things like Mustache {{ foo }} and
`format-spec' which separate the format from the data but have an alias
for each data item. And at the other end we see your approach and
Ansible+Jinja and Perl etc. which directly refer to the variables in
scope and basically try to reinvent the language in a "portable" format
that can be embedded in a string. If you're set on doing this, please
just fall through to the underlying language, e.g.
"$(format \"%3.2s\" myvar) $(myothervar)"

CP> Also: how does format-spec deal with formatting sequences, like %-3.2d?

It doesn't. You would convert that before passing it to the function.
You can consider that a deficiency (if you prefer the printf style) or
good (if you like the Mustache style).

>> This one in particular is heading in the direction of the way Ansible
>> integrates Jinja templates, which I think is not great compared to a
>> more Lispy approach.

CP> I have no strong feelings either way. I like the way Python is going, so it
CP> feels natural to suggest the same direction for Emacs. I view it as a 
convenient
CP> DSL for producing strings, just like the loop macro is a good DSL for 
iterating
CP> and accumulating results — and we're a Lisp, so we're good at DSLs :)

I think it's good to experiment. As currently proposed, I wouldn't want
to *maintain* code that used your approach. But I could be wrong about
it, and my advice was based on personal intuition and experience. So I
hope you found it useful rather than discouraging :)

Ted