JEP445 meets JEP459

[Ian Darwin]

On 2/6/24 13:05, Brian Goetz wrote:
> 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.

You are, as usual, quite right. Therefore, one possible way to take it 
head on: in the System class, redefine "out" along the following lines 
(I realize that System.out is more complicated but this is the sketch):

public static PrintStream out = new PrintStream() {
|  public static void PRINT(String line) { println(line); }
};

and have this System.out.PRINT be auto-statically imported, like STR is 
(y first thought was just to add the method to PrintStream, but that 
would pollute the latter's namespace).

It avoids confounding the two ideas and paves over the rules about 
qualification.

Students will learn soon enough that System.out.println() can be used 
(when they start reading old code), but they don't have to learn it up 
front.

>
>
>
> 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/2b4ad8ba/attachment.htm>