Strings and things

[Cay Horstmann]

I am happy with the general direction.

I didn't understand the following sentence: "The only case handled by 
most other languages that support string interpolation is the simplest 
one -- uninterpreted concatenation."

In JavaScript, a tagged template literal does what I understand a 
TemplatePolicy instance to do. In Scala, so does a StringContext. Both 
mechanisms can return instances of arbitrary types, combining the 
fragments and interpolated values as they see fit. Actually, both do it 
a tiny bit more nicely, because instead of a templateString one gets an 
array of fragments.

In Scala, one can use macros for compile-time checking, which is 
probably not the sweet spot for Java. In JavaScript, one also gets (in 
an icky way) the raw string fragments, so one can process for example 
TeX with \epsilon and \cite. Or RTF. Not sure that's an important use case.

Anyway, you might want to reword the doc so that either it acknowledges 
that you are thinking along the same lines, or make it clearer where you 
go further.

Two more random thoughts.

1) I am wondering whether % formatting directives are common enough that 
you want to take on the work of collecting them and passing them to the 
processor. You have the power to use \% or \{...%...}, and then the 
implementor doesn't have to worry about things like %%.

2) I've always found it irksome that MessageFormat has a large overlap 
with String.format, but it uses its own ad-hoc syntax:

String pattern
    = "{0} zerstörte am {2,date,long} {1,choice,0#kein Haus|1#ein 
Haus|2#{1} Häuser}";

I haven't spent any thought on how to unify that with interpolation, but 
I thought I'd throw it out there.

Cheers,

Cay

On 16/09/2021 16:28, Jim Laskey wrote:
> Dear amber-dev,
> 
> Over on amber-spec-experts, I’ve posted a proposal for “string templates”. I
> hope people are as excited about this feature as we expect they will be.
> 
> As a brief reminder, the amber-dev list is not, in general, for language
> design discussions; this list is primarily for discussion of implementation,
> bug repoorts, experience reports, etc.  We should let the experts do their
> job without having to follow parallel discussions on multiple lists.
> 
> If people want to post brief, reasoned feedback on the approach,
> applicability, or usefulness (but *NOT* the syntax) of the proposal here,
> that would be fine. Please, let’s keep it constructive.
> 
> Cheers,
> 
> -- Jim
> 
> 

-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com