[e-lang] Defining DeepPassByCopy

[Kevin Reid]

On Feb 28, 2007, at 19:39, Mark Miller wrote:
> On 2/27/07, Kevin Reid <kpreid at mac.com> wrote:
>> ? e`a` :DeepPassByCopy
>> # value: e`a`
>>
>> ? e`a`.__optUncall()[0] :DeepPassByCopy
>> # problem: Not audited by DeepPassByCopy
>>
>> ? e`a`.__optUncall()[0] :PassByCopy
>> # problem: Not audited by PassByCopy
>>
>> Is this simply a bug?
>
> Yes. All Java classes in E-on-Java which implements  
> JOSSPassByConstruction should be reexamined to see if it should  
> also be considered pbc, PassByCopy, or DeepPassByCopy. The offender  
> relevant to the present bug are safe instances of StaticMaker,  
> where safe means importable using <import>.
>
> Once StaticMaker is fixed, we must then deal with the curious issue  
> of the ImportLoader (the class whose instances are bound in E to  
> "<import>"). ImportLoaders should be handled as a Data-E graph  
> exit, which is distinct from being itself DeepPassByCopy.

What I conclude from this is that the property which is interesting  
for boot-comm purposes is not DeepPassByCopy, but rather "deeply  
either PassByCopy or a graph exit". Defining this, and making the  
notion of "is a graph exit, for a comm system obeying the usual  
rules" reified in a guard/named property, will solve my current problem.

I had previously written in this message a section about how  
StaticMakers are not really PassByCopy because their definition is  
provided by the receiving system, but after further thought I have  
concluded that this is not really a concrete difference:  
*everything*'s definition is (at some remove) provided by invoking  
something which is a graph exit.

As a separate issue, please recall

   http://www.eros-os.org/pipermail/e-lang/2007-January/011771.html

; in it I suggest making not <import>, but a slightly different  
loader, be the one which is PBC.

> [out of order]
>> If not, what is the precise definition of DeepPassByCopy such that  
>> an object being DPBC but one of its components (the maker) not  
>> being is consistent? Is the maker position only required to be  
>> PassByConstruction?
>
> To the extent that the answer to the above question is "yes", all  
> the components of a DeepPassByCopy should themselves be  
> DeepPassByCopy. The current behavior is buggy. Thanks for catching  
> this.
>
> I'm unclear how to deal with the above <import> issue. What does E- 
> on-CL do?

E-on-CL has not had much use for DeepPassByCopy as yet. The issue for  
which I started this thread didn't come up until I was working on an  
intraprocess comm system for E-on-CL.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>