[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: String interpolation
From: |
Ted Zlatanov |
Subject: |
Re: RFC: String interpolation |
Date: |
Sat, 10 Dec 2016 21:53:59 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
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
Re: RFC: String interpolation, Lars Ingebrigtsen, 2016/12/10