<div dir="auto"><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Aug 9, 2025, 13:45 Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:</div><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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? What about the @? Is that one too? From the reviewer's point of view, there's no syntactic indication that there are *any* variable references here, because the only syntax we can assume they know is Java syntax.</div><div dir="auto"><br></div><div dir="auto">To truly emulate embedded language roles for variable references, each template processor would need to define its own bespoke, unpredictable, potentially context-sensitive rules for variable references. Consider a language like Bash, where an unbraced variable reference ends at the first character that is not valid in a variable name.</div><div dir="auto"><br></div><div dir="auto">I think my expectation for templates would be that, as long as the reviewer knows the *template system*—not the individual template processors, but the syntax for using templates—they should be able to answer those questions. It feels untenable to force reviewers to research individual template processors for questions as basic and security-sensitive as, "Is this template capturing PII?"</div><div dir="auto"><br></div><div dir="auto">But also, you could imagine a language template like</div><div dir="auto"><br></div><div dir="auto">    final int x = 42;</div><div dir="auto">    var e = JAVASCRIPT."() => { return x; }";</div><div dir="auto"><br></div><div dir="auto">that creates a JSExpression object, which can be passed to a hosted JavaScript runtime for evaluation. In JavaScript, that x is referencing a variable that has not been declared lexically, so it could capture a variable in the outer scope. Does that template capture the Java variable x declared above? Or would it use the global x variable in my hosted JavaScript runtime? Neither option is obviously correct, and both are limiting.</div><div dir="auto"><br></div><div dir="auto">If that syntax does capture the x from Java, how do I disable that so I can reference the JavaScript global? That's maybe not obviously useful for x, but what about variables like String or Function (since those are variables in JavaScript).</div><div dir="auto"><br></div><div dir="auto">And if that syntax doesn't capture the x from Java, then how would I express that when there's no JavaScript syntax for "reference this variable outside the runtime."</div><div dir="auto"><br></div><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 dir="auto"><br></div><div dir="auto">Chris Bouchard</div></div>