[External] : Re: String templates

[Archie Cobbs]

On Sat, Aug 9, 2025 at 2:49 PM Chris Bouchard <chris at upliftinglemma.net>
wrote:

> On Sat, Aug 9, 2025, 13:45 Archie Cobbs <archie.cobbs at gmail.com> wrote:
>
> The only answer to that question I can think of is that many languages
>> already have a lexical notion of a parameter or variable and don't need a
>> new one.
>>
>> For example, it would be cleaner to write  XPATH."($param/foo[@myattr])" instead
>> of  XPATH."\{param}/foo[@myattr]".
>>
>
> The problem, in my opinion, is that the only common denominator with
> templates is that we're writing Java. How does a code reviewer for this
> snippet know that XPath uses $ to introduce variable references?
>

I would assume that anyone reviewing some code that has bits of language A
embedded within larger bits of language B would be expect to understand
both A and B...?

>
> Both options require the template implementation to invent invent an
> escape syntax that JavaScript doesn't have. This isn't a problem just for
> JavaScript—how many languages with variable references also have a syntax
> for escaping that reference to some unknown outer host score? So why not
> just use a standard Java escape syntax instead?
>
> And finally, using in-language syntax for variable references precludes
> embedding anything more interesting that a variable. For example, compare
>
>     JAVASCRIPT."{ a: \{obj.x}, b: \{obj.y}, c: \{obj.z} }"
>
> with
>
>     var x = obj.x;
>     var y = obj.y;
>     var z = obj.z;
>     JAVASCRIPT."{ a: x, b: y, c: z }"
>
> The latter is more verbose and repetitive, and introduces an extra layer
> of indirection to know what's being used in the expression—all to avoid
> typing \{}.
>
> I'll say, I can see the appeal of language-specific sub-syntaxes from the
> point of view of an author who is familiar with each template processor
> they're using. But I don't feel like they're a big enough win for the cost
> in understanding for everyone else.
>

Ok you've convinced me... and also made me realize that is really part of a
larger problem, which is that template processors are (in general) only
ever going to support a limited set of lexical substitution locations. For
example, this most likely wouldn't work:

String string = "I say \"Hello\"\nTo the world\n";
var script = BASH."""
    bash -c "echo `echo \{string}`"
""";

because: is the template processor really going to understand (a) bash's
nested quoting rules, and (b) how echo(1) parses its command line
argument(s), and therefore by implication every other Unix command you
could possibly put in a bash script? So a bash script template processor is
likely only going to support the most basic substitutions, like
VAR=\{string}.

In other words there is a language nesting complexity blowup that will
limit the substitution flexibility of many templates (maybe this was
already obvious to everyone but me).

For another "nesting" example, one might think the following would be
reasonable to do:

String oldTagName = "foo-bar";
String newTagName = "hah-hah";
var xsl = XML."""
    <xsl:transform version="1.0" xmlns:xsl="
http://www.w3.org/1999/XSL/Transform">
        <xsl:template match="//Parent/*[name(.) = \{oldTagName}]">
            <xsl:element name="\{newTagName}"/>
                <xsl:apply-templates select="*"/>
            </xsl:element>
        </xsl:template>
    </xsl:transform>
""";

But is the XML template processor really going to be smart enough to
recognize this as an XSLT transform with an embedded XPath expression and
know that the substitution rules for oldTagName and newTagName are
different? Not likely.

So to wrap up: my ideas of "language-native" parameterization and template
syntax don't really add much - because templates are already limited in a
more fundamental way.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250811/86bf571c/attachment.htm>