<div dir="ltr"><div>Hi Chris,</div><div>all I ask is a one liner method like this:</div><div><br></div><div><div>BlockClosure>>handleExit</div><div>    ^self value: [:result | ^result]</div><div><br></div><div>The usage I'm doing is my own business.</div><div>It is indeed very procedural, and plenty of goto like because it's just a dumb piece of code for generating smoke tests for fdlibm.</div><div>If you want to know, I iterate other set of bits that I compose into Float with basicAt:put:<br></div><div>It does not need to be object oriented, nor to be nice, just efficient.</div><div>And I don't want to be clever when I don't need to!</div><div>Lazyness rules ;)<br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le dim. 9 déc. 2018 à 21:32, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Dec 9, 2018 at 4:37 AM Nicolas Cellier<br>
<<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
> when writing scripts, I often need the ability to interrupt a loop.<br>
<br>
I use #detect:ifFound:ifNone: for such cases.<br>
<br>
> This is the traditional break instruction of C/Python or more advanced exit of FORTRAN/ADA (we can tell from which nexted loop we exit).<br>
><br>
> I could use exceptions, but then handling exit from nested loops is tricky (see below).<br>
> One possible way to do it in Smalltalk is to use blocks, and interrupt with non local return.<br>
<br>
I find nested #detect:ifFound:ifNone:'s structurally elegant enough,<br>
that the "detect" nomenclature doesn't bother me.<br>
<br>
> ref <a href="http://lists.gnu.org/archive/html/help-smalltalk/2008-06/msg00077.html" rel="noreferrer" target="_blank">http://lists.gnu.org/archive/html/help-smalltalk/2008-06/msg00077.html</a><br>
><br>
> Object>>escape: aBlock<br>
>     "Give the ability to exit execution of aBlock by returning control to sender.<br>
>     aBlock will take an argument, which is a door for returning control.<br>
>     This is useful for breaking a loop, for example:<br>
>      self escape: [:exit | someCollection do: [:e | e fullfilSomeCondition ifTrue: [exit value]. e doSometing]]"<br>
>     aBlock value: [^self]<br>
><br>
> | sum |<br>
> sum := 0.<br>
> self escape: [:exitOuterLoop | someCollection do: [:e |<br>
>     self escape: [:exitInnerLoop | someOtherCollection do: [:e2 |<br>
>         e2 > e ifTrue: [exitOuterLoop value].<br>
>         e2 = e ifTrue: [exitInnerLoop value].<br>
>         sum := sum + e]]]].<br>
> ^sum<br>
<br>
You want to do non-local returns to outer blocks within the same<br>
method?  Yikes, I love spaghetti as much as anyone, but only to eat!<br>
Isn't a hierarchical composition of blocks, as conveyed by modern<br>
tile-based coding tools like Scratch and Etoys, tremendously easier to<br>
follow?  Non-local returns make a method procedural by nature,<br>
basically like sprinkling "goto"s into your code.<br>
<br>
> We can also use the escape: inside the loop to avoid chained ifTrue:ifFalse:<br>
> but it's then convenient to let escape: return a value:<br>
><br>
> Object>>escape: aBlock<br>
>     ^aBlock value: [:result | ^result]<br>
><br>
> aCollection collect: [:e |<br>
>     e escape: [:return |<br>
>         e < 0 ifTrue: [return value: e].<br>
>         e > 20 ifTrue: [return value: 401 ln].<br>
>        (e squared + 1) ln]]<br>
<br>
OMG, LOL!!  Arrgghh!  Please, just give me the "chained ifTrue:ifFalse:"!!!<br>
<br>
The closest I've ever gotten to this is to separate error-handling<br>
code from processing code, to make it more readable, thus:<br>
<br>
   | error |  error := [ ^ MyError signal: 'User not found' ].<br>
   ^ users at: requestedId ifAbsent: error<br>
<br>
The return only even being needed because Squeak does not support<br>
non-resumable Exceptions.<br>
<br>
> ref <a href="https://stackoverflow.com/questions/7547750/smalltalk-block-can-i-explicitly-set-the-returning-value-and-stop-executing-th/11532045#11532045" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/7547750/smalltalk-block-can-i-explicitly-set-the-returning-value-and-stop-executing-th/11532045#11532045</a><br>
><br>
> At that time, I found that amusing, now I find it useful.<br>
<br>
No way, I don't believe it...   :/<br>
<br>
> I don't see such support in trunk image, could we add it?<br>
> Do you think of a better name?<br>
> (not setjmp: please)<br>
<br>
If such an albatross must go in trunk, setjmp: would be good.<br>
<br>
> Unless you come with better alternatives...<br>
<br>
Whole composed expressions!<br>
<br>
> One thing that is questionable is that the receiver of escape: is void (escape: is a utility).<br>
><br>
> There is <a href="https://stackoverflow.com/questions/52683795/gnu-smalltalk-break-from-whiletrue-loop-without-return/52702174#52702174" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/52683795/gnu-smalltalk-break-from-whiletrue-loop-without-return/52702174#52702174</a><br>
<br>
It's "cool" for showing how terse the design of Smalltalk language and<br>
environment, but not something actually recommended to do I hope,<br>
since it simply makes the language more complex unnecessarily.<br>
<br>
My 2 cents.<br>
<br>
 - Chris<br>
<br>
> It start looking like FORTRAN/ADA exit instruction with explicit naming of loop but I don't like it better.<br>
><br>
> Maybe sending the message to the block itself sounds less arbitrary.<br>
><br>
> BlockClosure>>handleExit<br>
>     ^self value: [:result | ^result]<br>
><br>
> | sum |<br>
> sum := 0.<br>
> [:exitOuterLoop | someCollection do: [:e |<br>
>      [:exitInnerLoop | someOtherCollection do: [:e2 |<br>
>         e2 > e ifTrue: [exitOuterLoop value: nil].<br>
>         e2 = e ifTrue: [exitInnerLoop value: nil].<br>
>         sum := sum + e]] handleExit ]] handleExit.<br>
> ^sum<br>
><br>
> Though, I don't find such post-fixing satisfactory: exitOuterLoop and handleExit are too far from each other... Especially in scripts that tend to be longer than ordinary methods (we don't want to factor every quick and dirty procedure into proper classes/methods when there is no reuse objective or when they are too specific).<br>
><br>
<br>
</blockquote></div>