[e-lang] Defining DeepPassByCopy

[Mark Miller]

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.

> Is it correct to implement DeepPassByCopy as a recursive test for
> PassByCopy?

Leaving aside the above <import> issue, yes.

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

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM