<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Thanks for the response, and yes it was code reflection from Babylon I referred to, sorry for not being clearer.<br></div><div><br></div><div>Indeed full code reflection would be more powerful. My curiosity how the concepts relate was triggered by the fact that if the code reflection is limited to snippets with only aggregation (e.g. operator +) and two types (fragments and values) it seems to become very similar to string template processing:<br></div><div><br></div><div>// Code reflection processor</div><div>processor.apply(@CodeReflection () -> $"foo = " + bar); <br></div><div><br></div><div>// String template processor</div><div>processor.apply($"foo = \{bar\}");<br></div><div><br></div><div>Where $"..." is shorthand for a fragment literal in the code reflection case, and (obviously) a string template in the string template case.</div><div><br></div><div>For the code reflection case you could in principle offer a shorthand $"foo = \{bar\}" to mean the same kind of aggregation as $"foo = " + bar.<br></div><div><br></div><div>And similarly for the string template case it seems you could offer $"foo = " + bar as an alternative aggregation syntax, i.e. translate it to the same string template as $"foo = \{bar\}".<br></div><div><br></div><div>(I guess in such a world it would be a personal preferences which kind of aggregation style you would prefer: the one with fragments and values delimited by + or the one with everything inline in one string template literal. One advantage of the former would be that string literal values wouldn't need escaping, i.e. $"foo = " + "bar" vs $"foo = \{\"bar\"\}", and also line breaks could be more naturally inserted between the parts without having to use multiline text blocks.)<br></div><div><br></div><div>Yours,<br></div><div>Mikael Sterner</div><div><br></div><div><br></div><div>On Mon, Mar 18, 2024, at 19:04, Clement Cherlin wrote:<br></div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div class="qt-gmail_quote"><div dir="ltr" class="qt-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.)"<br></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,<br></div><div>Clement Cherlin<br></div></div><div dir="ltr" class="qt-gmail_attr"><br></div><div dir="ltr" class="qt-gmail_attr">On Mon, Mar 18, 2024 at 8:50 AM Clement Cherlin <<a href="mailto:ccherlin@gmail.com" class="">ccherlin@gmail.com</a>> wrote:<br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color: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).<br></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.<br></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.<br></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.<br></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,<br></div><div>Clement Cherlin<br></div></div><div><br></div><div class="qt-gmail_quote"><div dir="ltr" class="qt-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="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>Hi Experts!<br></div><div> <br></div><div> What is the relationship between string template processors and code reflection, and would it influence the design of string templates and their literals?<br></div><div> <br></div><div> 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></div><div> <br></div><div> Examples:<br></div><div> <br></div><div> // String template processor<br></div><div> <br></div><div> String table = "foo bar";<br></div><div> ResultSet r = s.executeQuery("SELECT * FROM \{table\}"); // Escape dynamic table names<br></div><div> <br></div><div> // Code reflection processors<br></div><div> <br></div><div> String table = "foo bar";<br></div><div> ResultSet r = s.executeQuery(@CodeReflection () -> "SELECT * FROM " + table); // Escape dynamic table names<br></div><div> <br></div><div> String value = "bar";<br></div><div> Pattern p = Pattern.compile(@CodeReflection () -> "foo = " + value); // Quote dynamic strings<br></div><div> <br></div><div> Matrix m = Matrix.eval(@CodeReflection () -> Matrix.diag(1, 2, 3) * Matrix.col(2, 3, 4)); // Matrix multiplication<br></div><div> <br></div><div> Document d = HTML.compile(@CodeReflection () -> Body.of(Div.of("Hello World!"))); // Escape strings<br></div><div> <br></div><div> 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></div><div> <br></div><div> (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></div><div> <br></div><div> Yours,<br></div><div> Mikael Sterner<br></div></blockquote></div></blockquote></div></div></blockquote></body></html>