[Cuis] [SOLVED] Re: Copy vs Clone

Phil (list) pbpublist at gmail.com
Fri May 15 19:12:41 CDT 2015


On Fri, 2015-05-15 at 10:19 -0300, Juan Vuletich wrote:
> Well, I took a look at the image you sent me (btw, neat stuff!). My 
> point is that usually we don't really need closures:
> 
> a) For control flow, all we need is code blocks. The compiler knows 
> that, and optimizes most cases, avoiding the creation of a real closure. 
> These are never serialized by themselves (maybe the complete method is 
> serialized).
> 
> b) Real closures. Used for new control structures, that the compiler 
> doesn't know about. Also used for functional programming and 
> continuations. Not really needed most of the time: Squeak existed 
> without closures for over 10 years. These are hard and expensive to 
> serialize.
> 
> c) "context free lambdas" a.k.a. "clean closures". State is stored in 
> objects. All state is passed to the block as arguments. These are easy 
> and cheap to serialize. A typical example for these is a sort block in a 
> SortedCollection.
> 
> The code you sent me uses b). It stores state in variables in the 
> context of the closure. But this is not really needed. I could convert 
> your code to c). See the attach. What I did is to take that state and 
> store it in an instance variable. There was yet another variable that 
> could simply be a temporal inside the block. Then, the default 
> implementation of Morph>>copy worked without problems.
> 
> I think it would be good to have different syntax for "clean" or 
> "context free" blocks. And encourage their use above real closures, 
> whenever possible.
> 

If it's handled at compile-time, what's the downside to letting the
compiler sort it out... is there not enough context for it to do so
reliably?  If there isn't, would a pragma do the job? (i.e. default to
shallow unless the compiler determines that deep is needed, and a pragma
could be one way of telling the compiler deep is needed)

> Cheers,
> Juan Vuletich

Thanks,
Phil





More information about the Cuis mailing list