<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Wow, those syntactical ideas sound really interesting. However, I think is very important to keep the Smalltalk syntax as minimal as possible, as imho this is one big advantage over other common languages like C*. Smalltalk stands out by its use of self-explaining messages instead
of non-intuitive keywords. So what would you think about the following?</p>
<p><br>
</p>
<p></p>
<div>foo <b>asZöglfrex</b></div>
<div> collect: [:x|x barf];<br>
select: [:y|y isKnorz];<br>
inject: Kiffle into: [:clomb :blui | clomb baz: blui]);<br>
sum</div>
<div><span style="font-size:12pt"><br>
</span></div>
<div><span style="font-size:12pt">(Or even override #yourself instead of using #receiver.)</span></div>
<div><br>
</div>
<div>The relevant implementation of Zöglfrex would be quite easy:</div>
<div><br>
</div>
<div>
<div style="font-family:Consolas,"Courier New",monospace; font-size:14px; line-height:19px; white-space:pre">
<div>
<div style="font-family:Consolas,"Courier New",monospace; font-size:14px; line-height:19px; white-space:pre">
<div>Object <span style="color:#0000ff">subclass:</span> #Zöglfrex</div>
<div> instanceVariableNames: <span style="color:#a31515">'receiver'</span></div>
<div> classVariableNames: <span style="color:#a31515">''</span></div>
<div> poolDictionaries: <span style="color:#a31515">''</span></div>
<div> category: <span style="color:#a31515">'Kernel-Objects'</span></div>
<br>
</div>
Zöglfrex >> doesNotUnderstand: aMessage</div>
<div> ^ receiver := aMessage sendTo: receiver</div>
</div>
</div>
<p></p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.de><br>
<b>Gesendet:</b> Mittwoch, 11. September 2019 10:52:39<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] collect:thenDo: woes</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi<br>
<br>
> On 11.09.2019, at 09:42, Stéphane Rollandin <lecteur@zogotounga.net> wrote:<br>
> <br>
> Richard O'Keefe is making good points against the Squeak implementation of method #collect:thenDo: in the Pharo-users list:<br>
> <br>
> <a href="https://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044204.html">
https://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044204.html</a><br>
<br>
I read it. I see his point but I am attempted to disagree.<br>
<br>
Here's my reasoning: <br>
<br>
#collect:thenXXX: for me implies that the block of the collect-part has to abide the same constraints as a "pure" collect.<br>
<br>
That is, if you do <br>
'abc' collect: [:x | x asMorph]<br>
and this fails, then<br>
'abc' collect: [:x | x asMorph] thenDo: [:m | m openInHand].<br>
MUST also fail.<br>
<br>
Collect is bound to the kind of collection it collects over. <br>
We have #collect:as: for kind/species-changing collects.<br>
So to support Richard's case, one could imagine<br>
<br>
|o|<br>
o := OrderedCollection new.<br>
#[3 1 4 1 5 9]<br>
collect: [:byte | byte asFloat] as: OrderedCollection<br>
thenDo: [:float | o addLast: float].<br>
Transcript print: o; cr.<br>
<br>
(which makes the thenDo:-part superfluous, but I understand why the original version is that way)<br>
or for the other example:<br>
<br>
#[3 1 4 1 5 9]<br>
collect: [:byte | byte odd ifTrue: [byte printString]<br>
ifFalse: [byte]]<br>
as: Array<br>
thenSelect: [:each | each isNumber]<br>
<br>
<br>
<br>
> <br>
> I vote for the removal of this confusing method.<br>
<br>
[TL;DR below]<br>
<br>
<br>
The problem the #enumerationPart:thenOtherEnumerationPart: messages try to solve is our (otherwise helpfully) slim syntax.<br>
Because<br>
(((foo collect: [:x|x barf]) select: [:y|y isKnorz]) inject: Kiffle into: [:clomb :blui | clomb baz: blui]) sum<br>
is hard to write, error-prone and not "scriptable"[1].<br>
<br>
Marcel Weiher added syntax for this in his Objective-SmallTalk [sic] which would rather read like<br>
<br>
foo collect: [:x|x barf |> select: [:y|y isKnorz] |> inject: Kiffle into: [:clomb :blui | clomb baz: blui] |> sum<br>
<br>
or with breaks:<br>
foo<br>
collect: [:x|x barf |> <br>
select: [:y|y isKnorz] |> <br>
inject: Kiffle into: [:clomb :blui | clomb baz: blui] |> <br>
sum<br>
<br>
This makes it all very data-flow-y, which can be really great to understand what's going on with one's collections.<br>
<br>
Personally, I am not too keen on the '|>' symbolism itself, because |> is just another binary operator and would break current syntax.<br>
<br>
However, this whole thing is close enough to cascades we already got:<br>
<br>
forc<br>
gnarf: [kelp];<br>
klimb;<br>
strosn: [:f :zz | zz klept: f];<br>
badummdz.<br>
<br>
And _If_ we had something like it, I'd prefer it similarly to this.<br>
Maybe ;; (while somewhat stupid, its practical in its own right…), or use ! (no syntactical meaning yet, aside the changeset separation, but looks strange).
<br>
The ` is free but used in RefactoringBrowser's code matching and compiler error messages, so no good candidate either.<br>
<br>
Other syntactic variant, but even more out-of-place would be colon-doubling to signal "end of keywords":<br>
<br>
<br>
foo <br>
collect:: [:x|x barf] <br>
select:: [:y|y isKnorz] <br>
inject: Kiffle into:: [:clomb :blui | clomb baz: blui]) <br>
sum<br>
<br>
which is just one stop before Self's syntax, which abuses capitalization (watch for the Into):<br>
<br>
foo <br>
collect: [:x|x barf] <br>
select: [:y|y isKnorz] <br>
inject: Kiffle Into: [:clomb :blui | clomb baz: blui]) <br>
sum<br>
<br>
Btw: With higher order messages, it would also look quite good:<br>
<br>
<br>
(foo<br>
collect barf<br>
select isKnorz<br>
"inject: Kiffle into: [:clomb :blui | clomb baz: blui]" "<-- not sure here, tho"<br>
inject Kiffle<br>
into baz: blui)<br>
sum<br>
<br>
TL;DR: the ..:then..: messages have an important role in readability, so should we abandon them, we need something else, maybe even richer syntax.<br>
<br>
Best regards<br>
-Tobias<br>
<br>
<br>
<br>
[1]: With that, I mean, you can't forward-progam here. Think you star with some collection and inspect it. Then you go back to your do it,<br>
#collect: on it and inspect again. But then, to do the same with another, eg, #select:, first you have to put parenthesis around it, to then go to the end again and add your code. Repeat.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>