<div dir="ltr"><div dir="ltr">On Sat, Aug 9, 2025 at 10:00 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</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">I’m entirely with you, but I don’t see why that means that the *syntax for a template argument* needs to be different for every hosted language. Templates are an interface between Java and a hosted language, where the fragments are in the hosted language while the arguments are in Java. Since the arguments are in Java, why can’t their escape - i.e. the transition from the hosted language back to Java - be universal (i.e. `\{arg}`)?<br></blockquote><div><br></div><div><div>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><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><br></div><div>There's no reason you couldn't support both of course, but "native parameters" would come with a big new cost - the compiler would have to decode them at parse time, and that means supporting lexical extension plugins of some kind.</div><div><br></div><div>Which leads me to back up and ask this question. If T is the other (non-Java language), do we include T templates using (a) Java string literals (or string literals plus \{foo} placeholders), or (b) some kind of lexical escape/plugin mechanism that allows T to define whatever syntax it wants?</div></div></div><div><br></div><div><div>Option (b) is more complicated compiler-wise but provides a cleaner result. You could reference variables using T's native format (as described above) and also not have to use text blocks to avoid backslash hell, e.g., you could write: JSON<span style="font-family:monospace">.{ "a": 123, "b": false }</span></div></div><br><div>Would option (b) be worth the extra trouble? It would have complexity on par with annotation processing, which we found worth doing, so I feel like it's not entirely crazy to ask the question.</div><div><br></div><div>However, I'm guessing it's probably not worth the extra trouble unless this would open up some cool new capabilities that we haven't thought of yet.</div></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">-Archie</div><div class="gmail_quote gmail_quote_container"><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>