[squeak-dev] The Inbox: Kernel-ct.1405.mcz

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Sun Aug 22 15:33:59 UTC 2021


Hi Jaromir,

sorry, I had already addressed your ProceedBlockCannotReturn warning in [1] instead - but this thread is definitely the better place to continue this discussion. :-)

As already mentioned there, I doubt that warning the user again after he/she already had deliberately proceeded from an interpreter error makes much sense. But this is also not a strong opinion, so once again I'm calling for a third opinion here!

---

To now address this example:

> > ```
> >         sender := thisContext swapSender: nil.
> >         true ifTrue: [^ 1]. "Proceed the BlockCannotReturn"
> >         thisContext privSender: sender.
> >         ^ 2
> > ```

Very unfortunately, I cannot reproduce any longer what I have reported there myself. But the computation terminated is also wrong, IMO, you should get a BlockCannotReturn here. closureOrNil is nil here because the compiler does inline the ifTrue instruction - add a yourself behind the [^ 1] and you will get a correct BlockCannotReturn which you also can resume from to return the 2. Anyway, I originally brought the example to illustrate that all the VM optimizations with inlined message sends and whatever else could possibly destroy our assumptions about returnable blocks and contexts. But for the superordinate discussion here, I just would treat this as an imperfect VM implementation but nothing to worry about. :D

> BUT
> 
> if you debug it and:
> A) step through the ^1 - you get Message not understood
> B) step into ^1 - you don't get any error and can happily continue

Ouh, these are several simulator bugs. And if you forego the enclosing [] value and step into the ^1, you get just a different MNU ... This should be addressed, too. :-)
Without the enclosing [] value, I could fix both buttons by inserting the following in Context >> #return:from: right after the assignment to newTop which you can try out by loading Kernel-ct.1409 frmo the inbox.
With the enclosing [] value, however, it is not that easy. Case B) you mentioned is worst. In this example, the simulated snippet answers 1 instead of 2! If you debug the simulator ("debug button action" of the "Into" button in the last step), you can see that the difference here is that unless the VM executor, the simulator knows about the home context of the top context even if the latter has a nil sender (see Context >> #methodReturnTop). I can't tell which one of them is wrong, but they are not consistent, this is not good. ^^

Best,
Christoph

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216211.html

---
Sent from Squeak Inbox Talk

On 2021-05-30T11:50:52-05:00, m at jaromir.net wrote:

> Hi Christoph,
> 
> >
> > ... my point here is: Proceeding from an error almost always doesn't seem
> > "right". :-) It is always a decision by the debugging programmer to
> > override the default control flow and switch to the "next plausible
> > alternative control flow", i.e., resume as if the error would have never
> > been raised. Applied to the attempt to return from a method, for me, this
> > means to ignore the return (thinking of it in message sends: to ignore the
> > "thisContext (home) return"). Yeah, and if there is no further statement
> > after that return, my best understanding of the user's intention to
> > "proceed" would be to return to the place from where the block has been
> > invoked ...
> 
> Agreed :) The more I think about it the more I like it ;) And well, the
> non-local return could have been a typo anyways... so actually, this makes
> the best sense and preserves all options open for the user - perfect!
> 
> > Also, can you convince me why you would need some extra state in the
> > exception for this?
> 
> No, I hated adding an extra state :) The only thing I really need for the
> full #terminate to work correctly is a way to distinguish between normal
> proceeding the computation and resuming the unwind procedure when the
> BlockCannotReturn error occurs inside an unwind block currently being
> evaluated. All I need then is a Warning the computation proceeds beyond the
> BlockCannotReturn; here's what I mean:
> 
> ```
> cannotReturn: result
> 
>     closureOrNil ifNotNil: [
>         | resumptionValue |
>         resumptionValue := self cannotReturn: result to: self home sender.
>         ProceedBlockCannotReturn new signal: 'This block has ended, continue with
> sender?'.
>         self pc > self endPC ifTrue: [
>             "This block has ended, continue with sender"
>             thisContext privSender: self sender].
>         ^ resumptionValue].
>     Processor debugWithTitle: 'Computation has been terminated!' translated
> full: false
> ```
> 
> So if you're fine with this addition, full #terminate would recognize when
> it's beyond BlockCannotReturn and would continue unwinding the non-local
> return accordingly.
> 
> I think it's useful to warn the user about such an unusual (and new) option
> as Proceeding safely beyond BlockCannotReturn anyway :)
> 
> >
> > Argh, here is another example which does not yet match my expectations:
> > ```
> > sender := thisContext swapSender: nil.
> > true ifTrue: [^ 1]. "Proceed the BlockCannotReturn"
> > thisContext privSender: sender.
> > ^ 2
> > ```
> > I think this should eventually answer 2. Apparently, the VM already has
> > reset the pc in this example so we are helpless here. 
> 
> There's something wrong with this example :) (or my understanding of it)
> 
> 1) if you print-it or do-it you get Computation terminated instead of Block
> cannot return
> 
> 2) so I wrapped it in [] value
> ```
> [sender := thisContext swapSender: nil.
> true ifTrue: [^ 1]. "Proceed the BlockCannotReturn"
> thisContext privSender: sender.
> ^ 2] value
> ```
> Now it raises BlockCannotReturn and returns 2 with your changeset (if
> Proceeded)...
> 
> BUT
> 
> if you debug it and:
> A) step through the ^1 - you get Message not understood
> B) step into ^1 - you don't get any error and can happily continue
> 
> I'm confused...
> 
> Many thanks for your comments and your proposed solution to cannot return;
> I'll update #terminate and remove my previous attempts from the Inbox.
> best,
> 
> 
> 
> -----
> ^[^ Jaromir
> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210822/29b7f4fa/attachment.html>


More information about the Squeak-dev mailing list