<div dir="ltr"><div dir="ltr">On Sat, Aug 9, 2025 at 2:49 PM Chris Bouchard <<a href="mailto:chris@upliftinglemma.net">chris@upliftinglemma.net</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Aug 9, 2025, 13:45 Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>> wrote:</div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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.</div><div class="gmail_quote"><div><div><br></div><div>For example, it would be cleaner to write <span style="font-family:monospace">XPATH."($param/foo[@myattr])" </span><font face="arial,sans-serif">instead of</font><span style="font-family:monospace"><font face="arial,sans-serif"> </font>XPATH."\{param}/foo[@myattr]"<font face="arial,sans-serif">.</font></span></div></div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">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?</div></div></blockquote><div><br></div><div>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...?</div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">And finally, using in-language syntax for variable references precludes embedding anything more interesting that a variable. For example, compare</div><div dir="auto"><br></div><div dir="auto"> JAVASCRIPT."{ a: \{obj.x}, b: \{obj.y}, c: \{obj.z} }"</div><div dir="auto"><br></div><div dir="auto">with</div><div dir="auto"><br></div><div dir="auto"> var x = obj.x;</div><div dir="auto"> var y = obj.y;</div><div dir="auto"> var z = obj.z;</div><div dir="auto"> JAVASCRIPT."{ a: x, b: y, c: z }"</div><div dir="auto"><br></div><div dir="auto">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 \{}.</div><div dir="auto"><br></div><div dir="auto">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.</div></div></blockquote><div><br></div><div><div>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:</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">String string = "I say \"Hello\"\nTo the world\n";</span></div><div style="margin-left:40px"><span style="font-family:monospace">var script = BASH."""</span></div><div style="margin-left:40px"><span style="font-family:monospace"> bash -c "echo `echo \{string}`"</span></div><div style="margin-left:40px"><span style="font-family:monospace">""";</span></div></div><div><br></div><div>because: is the template processor really going to understand (a) bash's nested quoting rules, and (b) how <span style="font-family:monospace">echo(1)</span> 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 <span style="font-family:monospace">VAR=\{string}</span>.</div></div><div><br></div><div>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).</div><div><br></div><div>For another "nesting" example, one might think the following would be reasonable to do:</div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">String oldTagName = "foo-bar";</span></div><div style="margin-left:40px"><span style="font-family:monospace">String newTagName = "hah-hah";</span></div><div style="margin-left:40px"><span style="font-family:monospace">var xsl = XML."""</span></div><div style="margin-left:40px"><span style="font-family:monospace"> <xsl:transform version="1.0" xmlns:xsl="<a href="http://www.w3.org/1999/XSL/Transform">http://www.w3.org/1999/XSL/Transform</a>"></span></div><div style="margin-left:40px"><div><span style="font-family:monospace"> <xsl:template match="//Parent/*[name(.) = \{oldTagName}]"></span></div></div><div style="margin-left:40px"><div><div><span style="font-family:monospace"> <xsl:element name="\{newTagName}"/></span></div></div></div><div style="margin-left:40px"><div><div><span style="font-family:monospace"> <xsl:apply-templates select="*"/></span></div></div></div><div style="margin-left:40px"><div><div><span style="font-family:monospace"> </xsl:element></span></div></div></div><div style="margin-left:40px"><div><div><span style="font-family:monospace"> </xsl:template></span></div><span style="font-family:monospace"></span><span style="font-family:monospace"> </xsl:transform></span></div></div><div style="margin-left:40px"><span style="font-family:monospace">""";</span></div><div><br></div><div>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 <span style="font-family:monospace">oldTagName</span> and <span style="font-family:monospace">newTagName</span> are different? Not likely.</div><div><br></div><div>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.</div><div><br></div><div>-Archie</div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>