What would Squeak be like without non-local returns
Rob Withers
reefedjib at yahoo.com
Wed Nov 7 17:20:28 UTC 2007
----- Original Message -----
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, November 06, 2007 9:38 PM
Subject: Re: What would Squeak be like without non-local returns
> Rob Withers wrote:
>> Well, now I can't find that statement, but I was sure I had read it on
>> erights or Mark's thesis. I searched and found nothing. It may have
>> been a statement regarding eventual-sending specifically with non-local
>> return. It IS strange thinking about the correct behavior of an
>> expression:
>>
>> object eventual ifTrue: [^3].
>> ^4
>>
>> What should be the result?
>
> Without any question, 4. Since ifTrue:[] is sent eventual it will return
> immediately (answering a promise), and the method will continue and return
> 4. There is absolutely no question about it.
>
> When the eventual ifTrue: is executed it will barf because it will try to
> return from a method with no home but that's the way out-of-scope blocks
> go. It's just as well-defined as a non-local return from an out-of-scope
> block today, e.g.,
>
> Foo>>createBlock
> ^[^self]
>
> Foo>>callBlock
> self createBlock value.
>
> This will simply signal BlockCannotReturn and the eventual ifTrue:[]
> will - and should - do the same.
This makes that percieved problem of non-local returns with eventual sending
just go away. I am totally convinced.
The only difference I have at the moment, is that instead of getting an
unhandled BlockCannotReturn exception thrown, SqueakElib instead catches the
exception and resolves the promise for the eventually send #ifTrue: to be a
broken ref. Since that promise was never utilized, it quietly goes away -
it never opens the notifier. I am torn whether this is the correct thing to
do.
Cheers,
Rob
>
> Cheers,
> - Andreas
>
>
More information about the Squeak-dev
mailing list
|