[Cuis] [SOLVED] Re: Copy vs Clone

[Juan Vuletich]

Hi Ken,

On 5/15/2015 8:14 PM, Ken.Dickey wrote:
> 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.

I didn't know they were that important for you. Fortunately, and thanks 
to Eliot, we have closures in Cuis. Not having you around would be a big 
loss.

>>>> Sometimes I think it would be nicer if all closures were clean. I'm not
>>>> really sure what would we lose with such restriction...
> Looking out from the other side of the mirror, Schemers had the saying "Objects are a poor man's Closures".  I have implemented quite a number of object systems in Scheme in a variety of styles.
>
> 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!


>> 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:
> Right.  I can flatten environments by hand instead of letting the compiler do it.  Call me lazy.
>
> However, one can serialize closures and might be called lazy if that bit is left undone.  ;^)

Hehehehe. You might be right. But it is also true that if you just 
serialize any closure, without checking the consequences, en many cases 
you could end serializing the whole Smalltalk image. I guess it was one 
of the Fuel papers that talked a bit about this.

> Given the seemingly continuous changes in compilation strategies with Squeak/Pharo, I would not choose to do this in neglect of more fun things to do.
>
> The problem in this case is not that copy serializes Morphs, but that in the absence of network export it should NOT be serializing closures.
>
> That would be killing flies with a sledge hammer.

I am _really_ not sure about this. Maybe one morph holds a closure that 
has state stating if this morph is stepping or not. Then you duplicate 
your morph, and in #postCopy you are careful enough to avoid sharing 
state, so that the original and the copy are separate, independent 
objects. But the original and the copy will always share the closure, 
and the associated state. With our current inspectors, browsers and 
debuggers, "good luck debugging that sh*t". (Apologies for the language. 
It is a joke to my good friend Andrés, and I can't help it).


>> 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.
> Again.  Thank you very much for taking the time and trouble to do this.  It was very thoughtful of you.

My pleasure. Many times "a picture is worth a thousand words".

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

:) I will not judge your style or taste! I'm just a bit sorry that Cuis' 
support for Closures might not be good enough.

Cheers,
Juan Vuletich