[External] : Re: String templates

[Archie Cobbs]

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 }

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.

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.

-Archie

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