Copy vs Clone

> 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.
>

> Hi Juan,
>
> Thanks for your time and the example code.
>
> As a long time user of Scheme, Lisp, Dylan, and other languages we have some differences of opinion.
>
> Personal reflections follow.
>
>
>> Squeak existed without closures for over 10 years.
> Yes. Squeak ignored the Smalltalk standard.
>
> This is a polarizing issue for some people.  I refused to use Squeak until closures were supported.

>> 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.
> Again, I am lazy.  I am used to letting the compiler do the work of optimizing environments and using closures to prototype until I figure out the typical usage pattern(s).
>
>
>> 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.
> I am just not used to flattening and managing environments by hand, used real closures for too many years.  As you saw from
> http://www.iro.umontreal.ca/~feeley/papers/FeeleyLapalmeCL92.pdf
> I know how to play compiler, and I have done enough runtime work (wrote a GC in 88k assembler among other things) to know the basics.
>
> I guess I may have to be less lazy.
>
> What a shame!   ;^)
>
> Thanks again,
> -KenD

> 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)

> 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).
>

> 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.
>

> On Sat, 16 May 2015 18:01:23 -0300
> Juan Vuletich<[hidden email]>  wrote:
>
>>> Closures and Objects are in a sense duals.  One can implement Scheme in Smalltalk or Smalltalk in Scheme. I did an implementation of R5RS Scheme in Squeak which passed the test suite.  So call me linguistically promiscuous.
>> Thanks. This made me read a bit about this duality. It was enlightening.
>>
>> Wow! is that Scheme available somewhere? Please port it to Cuis!
> Juan, you may be the only person in the world interested in this -- especially after I explain the details.
>
> I had intended to compile to bytecodes, but the Squeak compiler was in its perennial state of flux, so I did a translator.
>
> I wrote a very small kernel for Scheme runtime support in Smalltalk, wrote a file based translator from Scheme->SqueakSmalltalk in Scheme.  This included a full R5RS Scheme reader in Scheme.
>
> Using a Scheme system, I ran the Scheme translator code to translated the translator into Smalltalk.  The resulting translator, running in Smalltalk, then could translate itself.
>
> I used the translated translator to translate the R5RS test suite into Smalltalk.  The entire test suite passed except for two small edge cases.  Note that the passing tests included Call/CC.