Translation musings (was: Are templated string embedded expressions "method parameters" or "lambdas"?)

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "John Rose" <john.r.rose at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Mardi 2 Novembre 2021 18:43:29
> Subject: Translation musings (was: Are templated string embedded expressions
> "method parameters" or "lambdas"?)

> I think we need to redirect a bit.

>> I’m pointing out a different proposition: *If* you need static validation of a
>> string, *then* you need something constant about the receiver. By constant I
>> mean, very specifically, “fixed no later than just before the first execution
>> of of the string template expression”. The “something constant” might be the
>> type (some subtype of a known “ST-Handler”), or it might be a constant value
>> (e.g., a static final field value).

> And I'm saying something different:

> - We never *need* static validation of the string.
> - We never *need* an indy-based, multi-step translation.

> Both of these are nice to haves, not must-haves; the goal is to extract these
> when we can have them, not to restrict the feature so that we can't use the
> feature if we can't produce them.

> We are in deep danger of way over-rotating towards the translation. I would go
> as far as to say that if we always, now and for the forever future, just
> translated with "invokeinterface", it would *still* be a successful and popular
> feature. Do we want to do better when we can? Of course. Are we willing to
> restrict the feature to the cases where can do so? Absolutely not.

> It's really easy to get wrapped around the axle over cases like String::format,
> and convince ourselves that this is the 99% use case. But this represents only
> a slice (yes, an important slice) of the benefits we get from this feature. In
> many cases, the work we'll do to translate the template (e.g., a CLASS."public
> class Foo { ... }" policy) or after we translate the template (execute a SQL
> query) completely dominates the performance profile.

> So yes, let's optimize for the best-case translation when we can, but let's not
> let that constrain what feature we deliver.
Templated strings can have a awful performance model if we are not careful, and i don't think that relying on the user being careful aka the C++ strategy is a good strategy. 

They have been enough lengthy discussions about the performance of String.format() vs StringBuilder, i think it's reasonable to avoid to create new performance pot holes when designing this feature. 

So static validation and being indy-based are a little more than just nice to have, they are here to provide an easy to understand performance model. 

regards, 
Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20211102/6f6f519d/attachment.htm>