<div dir="ltr"><div dir="ltr">Andres,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 2, 2019 at 2:42 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phil,<br>
<br>
On 10/14/19 23:48, Andres Valloud via Cuis-dev wrote:<br>
>> Taken together, I'd interpret that as any return value from the <br>
>> handler block is a gray area and implementer's choice.<br>
> <br>
> IIRC, there's non-zero truth in this.  But let's make sure, I'll do some <br>
> more digging tomorrow.<br>
The next to last paragraph in section 3.4.5.1 states that evaluating a <br>
block with a non-local return results in the abnormal-termination of all <br>
frames (the standard says 'functions') between the block's home context <br>
and the block's evaluation.  This is interesting for the following reason.<br>
<br>
Of course, when one writes something like<br>
<br>
        1 = 1 ifTrue: [^#lalala]<br>
<br>
irrespective of whether ifTrue: is optimized away, the net effect is <br>
that ifTrue: had actually been sent, evaluating the block would throw <br>
away the frame for ifTrue: and return from the method or expression <br>
where [^#lalala] appears.  That's ok because everybody knows ifTrue: is <br>
meant to be used that way.  Similar things happen with e.g.<br>
<br>
        1 to: 10 :: do: [:x | x isPrime: [^x]]<br>
<br>
because everybody knows that do: has no side effects and is safe to <br>
interrupt.  You can verify this by looking at the implementation of do:, <br>
and it is also the case that, typically, implementors of do: know that a <br>
non-local return may appear in the received block and so nobody writes <br>
do: to obstruct that usage.<br>
<br>
Asking for the abnormal-termination of exception frames is a different <br>
thing entirely.  I can believe most people can recite the implementation <br>
of do: from memory, but I would be really surprised if anyone could <br>
write an exception framework from scratch without spending some serious <br>
thought.  In short, I think there's a huge familiarity gradient in play <br>
here.<br></blockquote><div><br></div><div>Agreed and I think that's what I latched on to when you first raised the issue.  This *could* cause some ugly problems down the road.  Just because it doesn't currently doesn't mean it's not an issue as we might not actually see a problem until some useful enhancement down the road starts breaking things.</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">
<br>
Further, section 5.5.2.1 says nothing of what happens if an exception <br>
handler block has a non-local return, so the consequence might as well <br>
be undefined (because, literally, it is not defined).  (but if I missed <br>
the spot where it's defined, I'd be happy to see what it says)<br>
<br>
Given these, and from the experience debugging / fixing exception <br>
frameworks over the years I mentioned earlier, I conclude that using <br>
non-local returns in exception handler blocks is asking for trouble at <br>
best, and undefined at worst.  So, if I were to be the one writing code, <br>
I would not use non-local returns in exception handler blocks.<br></blockquote><div><br></div><div>I'm with you as far as '^' usage in an exception handler block goes.  I think where we have differing opinions is that I'm saying 'yes, let's eliminate ^ from exception handler blocks' but at the same time saying we should provide an explicit facility to allow for non-local returns (i.e. #methodReturn or whatever.)  This accomplishes three things:</div><div><br></div><div>1) Avoids potential issues down the road and/or being in the uncomfortable position of not being able to implement a feature because it will break code that could/should have been legitimately considered broken before.</div><div>2) Provides a mechanism with equivalent functionality that we know will *always* be correctly handled by the exception framework.</div><div>3) Makes the intent explicit (i.e. 'yes, I really did mean to do a non-local return in this exception handler')</div><div><br></div><div>I'm even in favor of saying 'from a best practices standpoint, we recommend trying to avoid using #methodReturn' if we wanted to... just provide it as an option.  If we did that, then I have no problem in flagging '^' in an exception handler as an error by default.  (Though we would might still want to keep a preference option to not have it be an error to help people porting code.)  It's taking away '^' without providing an alternate way to do it, especially when it's so trivial to do and logically consistent with the other functionality provided by the framework, that I have a problem with.  Let's use the Blue Book / ANSI as a starting point, not the destination.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't think I have much more to say about this.<br>
<br>
Andres.<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>