[Cuis] [SOLVED] Re: Copy vs Clone

[Juan Vuletich]

On Sat, May 16, 2015 6:17 pm, Phil (list) wrote:
> On Sat, 2015-05-16 at 18:05 -0300, Juan Vuletich wrote:
>
>> 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).
>>
>
> You answered my question:  the compiler is already doing it
> automatically.  I think I was getting caught up in a tangent of the overall
> conversation when you were talking about the cost (overhead) of closures.
> It wasn't clear to me if the compiler was handling the scope
> of the closure automatically or not so I was suggesting a pragma... but it
> sounds like it is handling this, so my point is moot.
>

Ok. This is all thanks to Eliot, who gave Closures to the Squeak world. He
did both the VM and Compiler work, I only brought it to Cuis.

Cheers,
Juan Vuletich