<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">
<div>Oh, I see, you were talking about code reflection from Project Babylon <a href="https://openjdk.org/projects/babylon/">https://openjdk.org/projects/babylon/</a><br></div><div><br></div><div>
<div>You asked, "Is the need to process string templates, seen as code snippets 
aggregating static and dynamic strings, just a special case of a more 
general pattern of processing code snippets semi-lazily using custom 
rules? (Such as safe handling of dynamic strings, or contextual operator
 overloading.)"</div><div><br></div>

</div><div>No, because String Templates are not code snippets, they're simple aggregations of strings and other values. Project Babylon deals in code snippets. They are related in the sense of making Java more expressive and able to deal with various DSLs and embedded expressions of various types, but they way they go about it is very different.<br></div><div><br></div><div>Cheers,</div><div>Clement Cherlin<br></div>

</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Mon, Mar 18, 2024 at 8:50 AM Clement Cherlin <<a href="mailto:ccherlin@gmail.com">ccherlin@gmail.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"><div dir="ltr"><div>Hi Mikael,<br></div><div><br></div><div>It looks to me like you're talking about a generic macro processor, not a string template processor. While that's an interesting idea, I think the scope is so much greater than string templates, it would make more sense as its own proposal (see <a href="https://openjdk.org/jeps/1" target="_blank">https://openjdk.org/jeps/1</a> and <a href="https://cr.openjdk.org/~mr/jep/jep-2.0-02.html" target="_blank">https://cr.openjdk.org/~mr/jep/jep-2.0-02.html</a> for details on the JEP process).</div><div><br></div><div>String templates, as currently designed, do not capture code snippets, but values. The value arguments to a template expression are evaluated to ordinary objects.</div><div><br></div><div>As stated elsewhere, a template object is simply a wrapper for the 
 N values

and N+1 string fragments of the template expression. The values are evaluated just like the parameters of any other Java constructor/method call. The source code or bytecode of the expressions that created the values is simply not available.</div><div><br></div><div>That said, if you want to pass Java code as strings to the template and do some magic with the Classfile API (now in preview) at runtime to generate code, you can. You can also use an annotation processor (like Lombok) or Java compiler plugin (like Manifold) to do all sorts of advanced manipulation of source/bytecode at compile time.</div><div><br></div><div>Lombok: <a href="https://projectlombok.org/" target="_blank">https://projectlombok.org/</a><br></div><div>Manifold: <a href="https://github.com/manifold-systems/manifold" target="_blank">https://github.com/manifold-systems/manifold</a><br></div><div><br></div><div>Cheers,</div><div>Clement Cherlin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2024 at 11:32 PM Mikael Sterner <<a href="mailto:msterner@openjdk.mxy.se" target="_blank">msterner@openjdk.mxy.se</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">Hi Experts!<br>
<br>
What is the relationship between string template processors and code reflection, and would it influence the design of string templates and their literals?<br>
<br>
Is the need to process string templates, seen as code snippets aggregating static and dynamic strings, just a special case of a more general pattern of processing code snippets semi-lazily using custom rules? (Such as safe handling of dynamic strings, or contextual operator overloading.)<br>
<br>
Examples:<br>
<br>
// String template processor<br>
<br>
String table = "foo bar";<br>
ResultSet r = s.executeQuery("SELECT * FROM \{table\}"); // Escape dynamic table names<br>
<br>
// Code reflection processors<br>
<br>
String table = "foo bar";<br>
ResultSet r = s.executeQuery(@CodeReflection () -> "SELECT * FROM " + table); // Escape dynamic table names<br>
<br>
String value = "bar";<br>
Pattern p = Pattern.compile(@CodeReflection () -> "foo = " + value); // Quote dynamic strings<br>
<br>
Matrix m = Matrix.eval(@CodeReflection () -> Matrix.diag(1, 2, 3) * Matrix.col(2, 3, 4)); // Matrix multiplication<br>
<br>
Document d = HTML.compile(@CodeReflection () -> Body.of(Div.of("Hello World!"))); // Escape strings<br>
<br>
Each such code reflecting processor API defining it's own rules for how to handle code snippets, including processing of any raw string templates when/if they are added to the language. Other types than String and StringTemplate being handled as fits each API, and to the level of type safety wanted by the API user. Evaluation being done lazily or eagerly as appropriate.<br>
<br>
(In the above "@CodeReflection () ->" is short for some syntax allowing inline code reflecting snippets, passed to the API processors in a way that allows them to reflect on the snippet code.)<br>
<br>
Yours,<br>
Mikael Sterner<br>
</blockquote></div>
</blockquote></div></div>