[External] : Re: String templates

[Ron Pressler]

> On 9 Aug 2025, at 18:43, Archie Cobbs <archie.cobbs at gmail.com> wrote:
> 
> On Sat, Aug 9, 2025 at 10:00 AM Ron Pressler <ron.pressler at oracle.com> wrote:
> 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}`)?
> 
> 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]".
> 
> 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.
> 
> 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?
> 
> 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.{ "a": 123, "b": false }

… and this, again, assumes that the template carries enough context for T to even decide whether the expression is valid syntax or not, which isn’t always the case (unless the “language identifier” also explicitly includes the relevant context kind, which is both complicated and adds burden on the programmer.