Hi Eliot,
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 (1s), 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.
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.
Personally, I am a large friend of String >> #format: and think that it has always does us a good turn. *Maybe* we could talk about supporting keyword arguments in #format: - for instance:
'Hi {name}! You made {count} contributions this year to the package {package}!' format: (OrderedDictionary new at: #name put: 'eem'; at: #count put: 18; at: #package put: 'Kernel'; yourself)
If performance is crucial for you, you still could inline String >> #format: message sends. But I have the feeling that this will mainly only increase complexity in the Compiler/Decompiler logic.
(Apart from that, I'm having some loose ideas in mind on an implementation of #formatAttributes: - maybe in the holidays.)
Nevertheless, I am open to hear your thoughts behind this idea! :-)
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2021-12-06T09:49:58-08:00, eliot.miranda@gmail.com wrote:
And here are three relevant emails
https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...
https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...
https://forum.world.st/Re-vwnc-Does-anyone-have-a-new-string-literal-tp46670...
_,,,^..^,,,_ (phone)
On Dec 6, 2021, at 9:41 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
Hi Christoph,
On Dec 6, 2021, at 9:02 AM, Christoph.Thiede at student.hpi.uni-potsdam.de wrote:
Hi all,
I'd like to push this discussion again before we ship the next release.
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.
From Wikipedia:
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] 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]
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. 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: Inbox: Compiler.quasiliteral-eem.280 Tests.quasiliteral-eem.296
_,,,^..^,,,_ (phone)
Best, Christoph
Sent from Squeak Inbox Talk