[External] : Re: String templates

[Olexandr Rotan]

>
> … 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.


Regarding the context part, I think that Graal polyglot is a good example
of how language interoperations are currently most commonly implemented.
Basically, most of the time some kind of context is created, and the
globals are defined before evaluation. Same pattern with, for example, Jexl
and Jxlt for templates and expression evaluation. The very naive
implementation may be to provide some opt-in mechanism for the template
processor to capture *values* from the outer scope, similarly to what
lambdas and inner classes do. However, this would require template
processors to be allowed to be instances, and not just classes (which, I
assume was allowed in the original proposal), and that brings us to the
point of being unable to validate syntax at the compile time, because where
there are instances instead of classes, there is polymorphism. Say we have
a "parser" processor instance, which can either parse XML or JSON,
depending on the implementation of the type. This lack of information
forces syntax validation to be deferred to the runtime instead of
compile-time.

The takeaway here is that compile-time validation is only an option for
static processors, which largely narrows the range of use cases for them.

On the side note, I fear that custom syntax validation at compile time may
dramatically increase build time, and noone wants Java to compile slower
the C++, i guess

Regards

On Sat, Aug 9, 2025 at 10:55 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250809/bb4668be/attachment-0001.htm>