Hi Eliot,<br>
<br>
I'm open to hear different positions, but IMHO quasi literals/template strings/interpolation strings in Smalltalk would violate the central idea of a minimal set of syntax that fits on a postcard. My personal opinion is that with number suffices (<font color="#800000">1s</font>), byte arrays, brace notation, etc., we have already blown up our syntax more than enough - that postcard will already cost you a lot of postage. And while I see the reasons behind these constructs, they still remaining syntax sugar or optimizations.<br>
<br>
In particular about template strings, I think that they tend to impair readability as user strings and syntactical expressions are intermixed. Programmers are tempted to violate separation of concerns. Last but not least, we would need to adapt the tooling in the decompiler and Autocompletion and alternative parser implementations (Shout) and I don't know whatever else. In general, this change would make new Smalltalk code more likely to be incompatible with older environments.<br>
<br>
Personally, I am a large friend of <font color="#000000">String</font><font color="#000000"> </font><font color="#000080">>></font><font color="#000000"> </font><font color="#000080">#format:</font> and think that it has always does us a good turn. <i>*Maybe*</i> we could talk about supporting keyword arguments in <font color="#000080">#format:</font> - for instance:<br>
<br>
    <font color="#800080">'Hi {name}! You made {count} contributions this year to the package {package}!'</font><font color="#000000"> </font><font color="#000080">format:</font><font color="#000000"> </font><font color="#000000">(</font><font color="#000000">OrderedDictionary</font><font color="#000000"> </font><font color="#000080">new</font><font color="#000000"><br>
        </font><font color="#000080">at:</font><font color="#000000"> </font><font color="#000080">#name</font><font color="#000000"> </font><font color="#000080">put:</font><font color="#000000"> </font><font color="#800080">'eem'</font><font color="#000000">;</font><font color="#000000"><br>
        </font><font color="#000080">at:</font><font color="#000000"> </font><font color="#000080">#count</font><font color="#000000"> </font><font color="#000080">put:</font><font color="#000000"> </font><font color="#800000">18</font><font color="#000000">;</font><font color="#000000"><br>
        </font><font color="#000080">at:</font><font color="#000000"> </font><font color="#000080">#package</font><font color="#000000"> </font><font color="#000080">put:</font><font color="#000000"> </font><font color="#800080">'Kernel'</font><font color="#000000">;</font><font color="#000000"><br>
        </font><font color="#000080">yourself</font><font color="#000000">)</font><br>
<br>
If performance is crucial for you, you still could inline <font color="#000000">String</font><font color="#000000"> </font><font color="#000080">>></font><font color="#000000"> </font><font color="#000080">#format:</font> message sends. But I have the feeling that this will mainly only increase complexity in the Compiler/Decompiler logic.<br>
<br>
(Apart from that, I'm having some loose ideas in mind on an implementation of <font color="#000080">#formatAttributes:</font> - maybe in the holidays.)<br>
<br>
Nevertheless, I am open to hear your thoughts behind this idea! :-)<br>
<br>
Best,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2021-12-06T09:49:58-08:00, eliot.miranda@gmail.com wrote:<br>
<br>
> And here are three relevant emails<br>
> <br>
> https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp4667088.html<br>
> <br>
> https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp4667088p4936208.html<br>
> <br>
> https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp4667088p4936241.html<br>
> <br>
> _,,,^..^,,,_ (phone)<br>
> <br>
> > On Dec 6, 2021, at 9:41 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:<br>
> > <br>
> > <br>
> > Hi Christoph,<br>
> > <br>
> >>> On Dec 6, 2021, at 9:02 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:<br>
> >>> <br>
> >> Hi all,<br>
> >> <br>
> >> I'd like to push this discussion again before we ship the next release.<br>
> >> <br>
> >> What do you think, can we finally disallow [:x] (without bar) via the Compiler? Or should we raise a DeprecationWarning at least? In the recent months, several occurences within the Trunk have already been adjusted.<br>
> > <br>
> > From Wikipedia:<br>
> > <br>
> > In microeconomic theory, opportunity cost, is what we get in return of an action[1] To elaborate, opportunity cost is the loss or the benefit that could have been enjoyed if the alternative choice was chosen. [2]<br>
> > As a representation of the relationship between scarcity and choice,[3] the objective of opportunity cost is to ensure efficient use of scarce resources.[4] It incorporates all associated costs of a decision, both explicit and implicit.[5] Opportunity cost also includes the utility or economic benefit an individual lost, it is indeed more than the monetary payment or actions taken. As an example, to go for a walk may not have any financial costs imbedded to it. Yet, the opportunity forgone is the time spent walking which could have been used instead for other purposes such as earning an income.[4]<br>
> > <br>
> > IMO fixing this isn?t very important. And the effort in fixing it takes away effort that could be applied from doing something useful.  There is a long list of things that we need to do, in the image, in the vm, in the community.<br>
> > If you want to work on something compiler related that would make a huge difference let me suggest quasi literals/template strings, with an attempt here:<br>
> > Inbox:<br>
> >     Compiler.quasiliteral-eem.280<br>
> >     Tests.quasiliteral-eem.296<br>
> > <br>
> > _,,,^..^,,,_ (phone)<br>
> > <br>
> >> Best,<br>
> >> Christoph<br>
> >> <br>
> >> ---<br>
> >> Sent from Squeak Inbox Talk<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211206/7343e1eb/attachment.html><br>
> <br>