Re: Features you would like to see

[Mark Hamburg <mhamburg@...>]

on 8/21/07 8:35 AM, David Given at dg@cowlark.com wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Hamburg wrote:
> [...]
>> I used to really want this and even made proposals in this regard. I've gone
>> back and studied the subtleties of Smalltalk blocks and realized that the
>> problem is a lot deeper than one would expect.
> [...]
>> Does the return exit the function and hence behave differently from a return
>> in:
> 
> One thing you can do in Smalltalk is to have the block return *after* the
> enclosing method has terminated! Consider:
> 
> handleClicksOn: o
> o whenButtonClickedDo: [ ^ true ].
> o enterMainLoop
> 
> (Calling whenButtonClickedDo: registers a callback on o that returns true;
> [...] defines a closure, ^ is return. enterMainLoop blocks and handles events.
> Smalltalk is, in a lot of ways, a very *concise* language.)
> 
> What happens if the main loop exits, handleClicksOn: terminates, and then
> somehow the user manages to click the button? Well, the standard doesn't
> actually say --- it's 'undefined'. The same thing applies if you manage to
> pass the closure off to a thread other than the one that actually created it.

The Scheme answer is that you get to return again from handleClicksOn.

But that's Scheme. ;-)

In fact, I sometimes explain first-class continuations to people by
proposing a syntax for non-local returns (e.g., return x from func1) and
then asking what happens when you invoke this after the appropriate
activation of func1 has already returned. The Scheme answer: It does exactly
what you asked for and it returns again.

I think the Dylan answer is that it's an error and Dylan presumably throws
an exception. Yes, you can argue that it isn't the fault of the call chain
that led to the block being called and trying to return, but to the extent
that an exception means "someone tried to do something they shouldn't" --
e.g., index a number -- this is an appropriate use for exceptions.

Mark