[Cuis] [SOLVED] Re: Copy vs Clone

[Juan Vuletich]

On 5/15/2015 9:12 PM, Phil (list) wrote:
> 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)

What Ken said is that the compiler can build closures for us, closing 
over the appropriate scope.

You suggest having hints for the serializer to be able to say what to 
duplicate and what not. This is an interesting idea. Right now, the 
things that are not duplicated are those we are sure we'll be able to 
find when deserializing. What you suggest means that serializing for 
local copying might mean sharing additional state. So serializing for 
copying for local use would be different from serializing for 
persistence, or for pasting into another Cuis image (local, networked, 
whatever).

Cheers,
Juan Vuletich