<div dir="ltr"><div dir="ltr">Andres,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 2:48 AM 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 22:37, Phil B wrote:<br>
> - Blue Book - Useless... the only thing remotely mentioning exceptions <br>
> had nothing to do with them. I don't see #on:do: referenced anywhere. <br>
> Wondering if Exception as we know it even existed back then? I see <br>
> things like SyntaxError hanging directly off of Object.<br>
<br>
IIRC, exceptions were a later invention.<br></blockquote><div><br></div><div>That would make sense. Blue Book etc. really seem most valuable re: the specification of the VM. I've always found their level of detail describing image-level behavior to be vague / spotty.</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>
> - ANSI draft - Now we're getting somewhere...<br>
> <br>> [snip]<br>
<br>
See section 5.5.2.1, which (if I'm reading it right) says that if a <br>
handler block does not tell the exception what to do, the behavior is <br>
equivalent to doing ex return: (the value of the block).<br></blockquote><div><br></div><div>Ah, yes... that would be my initial interpretation as well. (I had managed to skip over that section as I've been staring at too much text tonight. I'll need to re-read when I'm fresh)</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>
However, the text prefixes that specification by stating "if the block <br>
answers normally, as if returning from the message #value:". Ok, so now <br>
we have an interpretation problem.<br>
<br>
Does "answer normally" include non-local return?<br>
<br>
1. Suppose the answer is 'yes'. Then what does it mean to do<br>
<br>
ex return: anObject<br>
<br>
in order to return to a block that is no longer in the stack, because <br>
presumably the non-local return unwound the receiver of on:do: as well? <br>
This interpretation does not make sense.<br>
<br>
2. So suppose the answer is 'no'. Then what happens when the handler <br>
block has a non-local return? I do not immediately see what the spec <br>
says should happen, especially wrt the exception environment --- is that <br>
even supposed to be reset? I'd like to believe so, because otherwise <br>
consider the horrors of a non-local return skipping past exception <br>
handlers without resetting the exception environment to the closest <br>
still active handler.<br>
<br>
Maybe I missed the text that says what happens?<br></blockquote><div><br></div><div>I think I'm with you on this. I guess it depends on how one interprets Section 3.4.5.1 as it relates to exceptions? (i.e. is the home activation of the block considered terminated while in the exception handler? The fact that it may not be from a VM/image implementation standpoint doesn't necessarily mean that it shouldn't be logically... we are in an exceptional state after all and have redirected control flow for a reason. Or should we be thinking of exceptions really as just dressed up gosubs? I think at this point I'm just restating your original complaint on this...)</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>
> Taken together, I'd interpret that as any return value from the handler <br>
> 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>
<br>
> So as I believe you've <br>
> stated, the only way to ensure a specific return a value is to send <br>
> #return (for nil) or #return: (for any other value.) I find that more <br>
> than a bit scary since it means that the behavior before the most recent <br>
> changes was valid. And so was the behavior after the most recent changes.<br>
> <br>
> Unless someone can find something else to make be feel better, I'm in <br>
> full agreement that we do have a problem.<br>
<br>
Repeatedly running into this kind of situation is one of the things that <br>
often makes me wish programs were very explicit about what they want to <br>
happen. Because then, if (say) we wanted to change how exceptions work, <br>
then we can reimplement the messages the application sends so they <br>
provide the expected behavior in the new world, and everyone's happy.<br></blockquote><div><br></div><div>Exactly. It's not that I care so much which way things (in this case, Exception) work, only that it is consistent and documented so I can depend on whatever behavior is there not to change underneath my code.</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>
But if programs do not explicitly say what they mean, now we're in the <br>
business of guessing. There's no way to win that, so the steady state <br>
becomes 'nothing changes anymore'. Obviously that's unacceptable.<br></blockquote><div><br></div><div>Agreed. That's why I'm looking for anything that would either point us toward 'yes, this is valid/allowed' or 'no, it isn't'. If nothing exists, then sure it's fair game to make a call one way or the other. But to make that call if something exists that contradicts the decision may, depending on the source, be unwise.</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>
Andres.<br><br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>