<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="m_1457846166728384935gmail-m_-47594705073106758x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);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,</p></div></div></div></blockquote><div>I'm glad to hear you say that, Christoph, because I feel the Collection class>>#new:filledWith: proposal falls into the same category as this -- too many issues.<br></div><div><br></div><div>As a development community, I think we should consider moving some of these "syntactic sugar" method ideas into a new "Collections-Extensions" package which could be safely unloaded (e.g., no core code would depend on it).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="m_1457846166728384935gmail-m_-47594705073106758x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p>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></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="m_1457846166728384935gmail-m_-47594705073106758x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<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></div></div></blockquote><div><br></div><div>I don't understand this aversion to parentheses. They're the universal symbol of precedence, not only universally readable, but thanks to Squeak's built-in "expression editing" capabilities, enable a more powerful way to edit code than the sugary syntax that typically leave you "editing text" instead of expressions. </div><div><br></div><div>I generally don't care for added syntactic sugar that serves only to reduce parentheses. It's not worth the API explosion or costs in portability.</div><div><br></div><div>+1 to deprecate them or move them to an unloadable Collections-Extensions.<br></div><div><br></div><div>Best,</div><div> Chris</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="m_1457846166728384935gmail-m_-47594705073106758x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<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-wrap">
<div>
<div style="font-family:Consolas,"Courier New",monospace;font-size:14px;line-height:19px;white-space:pre-wrap">
<div>Object <span style="color:rgb(0,0,255)">subclass:</span> #Zöglfrex</div>
<div> instanceVariableNames: <span style="color:rgb(163,21,21)">'receiver'</span></div>
<div> classVariableNames: <span style="color:rgb(163,21,21)">''</span></div>
<div> poolDictionaries: <span style="color:rgb(163,21,21)">''</span></div>
<div> category: <span style="color:rgb(163,21,21)">'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="m_1457846166728384935gmail-m_-47594705073106758x_Signature">
<div name="x_divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_1457846166728384935gmail-m_-47594705073106758x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>><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="m_1457846166728384935gmail-m_-47594705073106758PlainText">Hi<br>
<br>
> On 11.09.2019, at 09:42, Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net" target="_blank">lecteur@zogotounga.net</a>> 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" target="_blank">
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>
</div>
<br>
</blockquote></div></div>