JEP445 meets JEP459

[Brian Goetz]

I'll just add one more point to try and illustrate why it makes me 
uncomfortable.  In the python example:

     print(f'Hello {name}, your balance is {balance}')

there are two mechanisms here -- f-strings and print().  And the two are 
completely orthogonal; I can put any string I want inside the parens and 
it works, and I can take the f-string and put the result wherever I can 
put a string.  Each can be designed independently, and reasoned about 
independently, and they meet at the String type, and because of that, 
they compose with no additional coordination.

The string processor suggested here complects two things that should be 
orthogonal: string interpolation and writing to stdout.  If I want to 
write to std out without interpolation (maybe I already have a string in 
hand), or I want to interpolate without printing, now I have to use 
another mechanism.  So it can't replace either println *or* STR, and 
that means people have to learn all three.  Whereas the status quo is 
more like the python example: we have template expressions using STR in 
the place of f-strings, and we have a method that takes any string and 
prints it.  The main defect of the status quo is the confusing rules 
surrounding qualification, but fixing that by denormalizing what is 
already a sensible separation of concerns is one step forward and two 
steps back.  Instead, we should address the qualification problem more 
directly.





On 2/6/2024 12:41 PM, Ian Darwin wrote:
> I see your main point but can't resist the odd quibble:
>
> On 2/6/24 12:14, Brian Goetz wrote:
>> Similar things have been suggested before, but there are two primary 
>> concerns here that make it a "clever" but 
>> unattractive-in-the-long-term direction.
>>
>> The main one is "the onramp should lead to the highway."  If we give 
>> a special, magic way to print templated strings, but nothing else, 
>> this is an easy incantation to teach, but it doesn't go very far.  If 
>> you want to do even a little bit more (e.g., print to a file, or to 
>> standard error, or just print out a string with no formatting, etc), 
>> you have to switch to a completely different mechanism, 
>
> A string with no formatting would be handled like any other, just as 
> STR."Hello world" yields (redundantly) a string with no formatting.
>
> Printing to a file is more complicated anyway as you don't usually get 
> there without meeting IOException and try/catch or at least throws.
>
> But yes, it is a different mechanism; as part of smoothing that out, 
> students can initially be taught that PRINT."..." is "just a shortcut" 
> for System.out.println(STR."..."); as a side benefit, they learn about 
> this string template that can be used anywhere.
>
>> and now you need to know TWO things and know when to use one or the 
>> other.  It is a shortcut that becomes a "beginner's dialect" because 
>> it does not lead smoothly to learning the "regular" language.
>>
>> Second, the possibility that a string template could have 
>> side-effects instead of (or worse, in addition to) just taking the 
>> ingredients and mixing them up into a composite thing makes the 
>> concept of string templates more complicated.  While we can't prevent 
>> people from sneaking side effects into their template processors, we 
>> shouldn't encourage this, or suggest that all users have to work this 
>> into their mental model. 
> But this template processor, like STR itself, would be a final field 
> in perhaps the StringTemplate class, imported automatically like STR. 
> It is your processor, not theirs.
>>
>>
>> So its possible, but I don't think its a good direction for the 
>> language.
> It's your call. Thanks for the feedback. I'll withdraw the suggestion 
> and hope that some day, some way can be found to simplify this 
> particular "speed bump". I respect that the team always holds off 
> until the best or "correct" way can be found.
>>
>> On 2/6/2024 11:54 AM, Ian Darwin wrote:
>>> While experimenting with the String Template feature, it occurs to 
>>> me that a relatively simple expansion of String Templates would pave 
>>> over another of those speed bumps. Basically:
>>>
>>>     PRINT."Hello \{name}. Your balance is \{amount}";
>>>
>>> Indeed, the beginner who hasn't yet met string templates can use the 
>>> degenerate case
>>>
>>>     PRINT."Hello world";
>>>
>>> and then later "need not discard what they learned in the early 
>>> stages, but rather they see how it all fits within the larger picture."
>>>
>>> This compares favorably with, e.g., Python 3's
>>>
>>> print('Hello world') and
>>>
>>> print(f'Hello {name}, your balance is {balance}')
>>>
>>> This seems like a fairly obvious extension, so I ask: Do you already 
>>> have such a thing up your collective sleeves or, if not, do you 
>>> think it might be grounds for a JEP proposal?
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240206/a26331b5/attachment-0001.htm>