<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">… 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.</blockquote></div><div><br>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.<br><br>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.<br><br>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<br><br>Regards</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Aug 9, 2025 at 10:55 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 9 Aug 2025, at 18:43, Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com" target="_blank">archie.cobbs@gmail.com</a>> wrote:<br>
> <br>
> On Sat, Aug 9, 2025 at 10:00 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br>
> 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>
> <br>
> 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.<br>
> <br>
> For example, it would be cleaner to write  XPATH."($param/foo[@myattr])" instead of  XPATH."\{param}/foo[@myattr]".<br>
> <br>
> 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.<br>
> <br>
> 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?<br>
> <br>
> 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 }<br>
<br>
… 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.<br>
<br>
</blockquote></div></div>