Right, but it looks like we have, what I would call real closures in the 
image, they just don't get used.  I was suggesting that perhaps if you see 
something like:

MyClass>>myMethod

a := SomeClass new.

^ [ :b | b use: a ]

Then the compiler turns that into a real closure, since it obviously needs 
to have that environment around after the method is gone.  And you don't 
have to look inside the block at what it is doing.  If a block gets returned 
from a method then that can only mean (I think) it's going to need a copy of 
the context it was created in.

For methods that pass blocks downward (i.e. they call methods passing 
blocks, but they will be around for the life of the block) then the current 
blocks are probably ok, since the context the block was made in has to stay 
around.

But then again, it's probably better to just do it right to begin with and 
not worry about such complexity.  You all would know the answer to that 
better then me.

>From: "Philippe Marschall" <philippe.marschall at gmail.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: When is a closure a real one? [was: Real closures]
>Date: Sun, 8 Oct 2006 17:30:03 +0200
>
>The problem is not non-local returns but block arguments/temps. Squeak
>just makes method temps out of them.
>
>Philippe
>
>2006/10/8, J J <azreal1977 at hotmail.com>:
>>I am not familiar enough with those calls to say 100%, but when I say 
>>"real
>>closures", what I mean are closures that can be returned from a function 
>>and
>>used without fear.  In other words, what other languages that have 
>>closures
>>do.
>>
>>Now I relize the "return to home context" (i.e. ^) is not compatible with
>>this, but that's ok.  This ability is unique to smalltalk as far as I know
>>and treating it different would be fine (e.g. if a ^ is seen then turn the
>>block into the cheaper BlockContext since it can't be returned from a 
>>method
>>anyway).
>>
>>Or for that matter if the speed problem is too hard to fix right now, then
>>maybe a simple change in the compiler to make a block into a BlockClosure 
>>if
>>it gets returned?  Obviously most of you know a lot more about this then 
>>me.
>>   Just throwing some things out there.
>>
>>
>> >From: "Klaus D. Witzel" <klaus.witzel at cobss.com>
>> >Reply-To: The general-purpose Squeak developers
>> >list<squeak-dev at lists.squeakfoundation.org>
>> >To: squeak-dev at lists.squeakfoundation.org
>> >Subject: When is a closure a real one? [was: Real closures]
>> >Date: Sun, 08 Oct 2006 10:51:25 +0200
>> >
>> >Thank you Mathieu and Phillipe for you pointers and example.
>> >
>> >Just out of curiosity (and as input for writing accurate yes/no test 
>>cases
>> >:) let me ask what is expected by the community (apologies if this 
>>sounds
>> >like a silly question ;-) when is a closure a real one:
>> >
>> >1] after #fixTemps (or equivalent)
>> >
>> >2] after #blockCopy: (is this equivalent to 1?)
>> >
>> >3] after #createBlock: (is this equivalent to 1? to 2?)
>> >
>> >4] <put: your requirements: or thoughts: here>
>> >
>> >Thank you for your time!
>> >
>> >/Klaus
>> >
>> >
>>
>>
>>
>>
>