String Template processors vs Code Reflection?

[Clement Cherlin]

Hi Mikael,

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 https://openjdk.org/jeps/1 and
https://cr.openjdk.org/~mr/jep/jep-2.0-02.html for details on the JEP
process).

String templates, as currently designed, do not capture code snippets, but
values. The value arguments to a template expression are evaluated to
ordinary objects.

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.

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.

Lombok: https://projectlombok.org/
Manifold: https://github.com/manifold-systems/manifold

Cheers,
Clement Cherlin

On Fri, Mar 15, 2024 at 11:32 PM Mikael Sterner <msterner at openjdk.mxy.se>
wrote:

> Hi Experts!
>
> What is the relationship between string template processors and code
> reflection, and would it influence the design of string templates and their
> literals?
>
> 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.)
>
> Examples:
>
> // String template processor
>
> String table = "foo bar";
> ResultSet r = s.executeQuery("SELECT * FROM \{table\}"); // Escape dynamic
> table names
>
> // Code reflection processors
>
> String table = "foo bar";
> ResultSet r = s.executeQuery(@CodeReflection () -> "SELECT * FROM " +
> table); // Escape dynamic table names
>
> String value = "bar";
> Pattern p = Pattern.compile(@CodeReflection () -> "foo = " + value); //
> Quote dynamic strings
>
> Matrix m = Matrix.eval(@CodeReflection () -> Matrix.diag(1, 2, 3) *
> Matrix.col(2, 3, 4)); // Matrix multiplication
>
> Document d = HTML.compile(@CodeReflection () -> Body.of(Div.of("Hello
> World!"))); // Escape strings
>
> 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.
>
> (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.)
>
> Yours,
> Mikael Sterner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20240318/623ef9ce/attachment.htm>