[Cuis] [SOLVED] Re: Copy vs Clone

Phil (list) pbpublist at gmail.com
Sat May 16 16:17:01 CDT 2015


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.

> Cheers,
> Juan Vuletich






More information about the Cuis mailing list