New string template approach.

[Duncan MacGregor]

So over Christmas I tried kicking the tires on string templates I by creating a method handle combinators library that worked with a small lisp DSL, because I had always described the method handles API to new developers as a lisp with really annoying syntax, so I thought I’d try and remove that syntax hurdle.

Overall I think it worked well, except that there was some friction in composing fragments (should I use RAW templates, provide an intermediate form, or make sure I could always decompose the MH structures in all the ways my library might need) and that if I expected a call site to be used frequently I lacked the sealed linkage mechanism that FMT could use.

Removing the processor from template literal declaration definitely steers things in a particular direction and should place all users on an even field in terms of implementation optimisations, and I’ll be very interested to see this when there is a branch available. I think the downside to this is that we will no longer see a clean correspondence of template literals to call sites that process them so I will be interested to see what performance boost we get on string formatting that couldn’t already be done with the existing format string.

The other thing I’d be interested to know in this new approach is how StringTemplates inserted as values into other templates will be treated. Simply as StringTemplate objects in the values list, or will they produce a string template that has been flattened? The new approach feels like it will encourage this approach of combining fragments and is likely to be something that many processors are going to need to handle.

Anyway, looking forward to seeing this new approach and trying this MH combinators prototype a second time.

Duncan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240311/79bf644e/attachment.htm>