Re: remote environments

[Gregor.pa@Xerox.COM]

In this message I question, once again, the existence of remote
metaobjects.  I may be behind the times here, but since no one answered
the long message I sent about why we could do without remote metaobjects
I am still stuck at that point.


    Date: Thu, 23 Feb 89  18:38:01 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

     * Can a MAKE-INSTANCE be done by a macro expander, DEFCONSTANT, or "#."? 

    Date: Mon, 6 Mar 89 21:37 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I think it would be much nicer if we could make compile-time classes
    instantiable.  However, I agree that it would not ruin the language to
    omit that feature if we can't figure out how to do it.


    Date: Fri, 10 Mar 89 16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    >		 One way to look at this would be to
    >       say that it is implementation-dependent whether FINALIZE-INHERITANCE
    >       works or signals an error when given a class defined in the
    >       compile-time environment.


I don't understand these comments.  It seems to me that the only real
questions are "is there a remote class object?" and "if so, how are
remote functions represented?".

If there is a remote class object then we must solve what I previously
previously called the `splicing' problem.  That remote class object must
have pointers to other class objects which represent its superclasses.
If that is the case, then to some extent that remote class will be
instantiable.  Any class that has direct supers can be finalized
provided that none of the supers are forward referenced.  Since it can
be finalized, allocate-instance can be called.  So, the only real
question is whether the initfunctions can be called.  From the user's
point of view, that translates into whether make-instance can be called.


    Date: Mon, 6 Mar 89 21:37 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    When you compile-file a DEFMETHOD, a method metaobject is created but it
    is not added to the generic-function metaobject in the local environment.
    Instead it is added to a different generic-function metaobject created
    in the remote environment.  That's my model of what has to happen.  Note
    that this should be completely consistent with the way that compile-file
    of a DEFCLASS, with a direct superclass whose name is defined in the 
    local environment and not in the remote environment, does not add the
    new class metaobject to the direct subclasses of the local superclass,
    but rather to a different object.  (I realize we haven't agreed on what
    this paragraph says, or even seen a coherent proposal, yet.  I'm just
    telling you my model.)

Yes, this is the `splicing' problem which must be solved to have remote
metaobjects.

    In the past there has been some controversy about whether the remote
    environment can inherit from the local environment.  I think this is
    crystal clear: since some user-defined classes have STANDARD-OBJECT
    as a direct superclass, and STANDARD-OBJECT is not defined in the same
    file, the remote environment is clearly inheriting from the local
    environment.  Different implementations might want to address the
    details of this differently, but I think it's clear that there has to
    be provision for it in the metaobject model.  It makes things more
    complicated, but that's unavoidable.

More splicing problems.


    Date: Fri, 10 Mar 89 16:49:44 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > This is an interesting idea, but I think it's too restrictive.  Here's a
    > plausible and many-times proposed application for metaobjects which
    > would not be possible if we adopted this idea.  Suppose you made an
    > optimizing compiler that is allowed to assume that no class
    > redefinitions, no method redefinitions, and no newly-defined subclasses
    > will be created at run time.  The compiler is to take advantage of this

    I certainly don't want to prevent any implementation from doing that.
    The real issue is what is the minimal functionality that all
    implementations must support.

As Moon says in a later message, the issue here is not what the
implementation can do, its what portable programs can do.  It needs to
be the case that one can write a portable, metaobject `compiler'.  Many
people have wanted to do this.  People currently do this with PCL which
surely has no remote metaobjects.

But, do we need remote metaobjects to do this?  I have argued before
that we don't.  I believe it would be a reasonable restriction on
such portable programs that the program they are `compiling' be loaded
before it can be compiled.  No one has shown me why that isn't the case.

But, what I know wonder is whether it would be a reasonable restriction
on implementors.  Because, with this metaobject stuff, we can specify
minimal behavior, but we can't specify minimally.  If we specify that
there are no remote metaobjects, then implementations are going to have
to prevent themselves from ever instantiating remote versions of
portable metaobjects.  Moreover they will have to be certain that user's
can't get their hands on remote metaobjects.  This will make life more
complicated for implementations, I don't know how much more complicated.
On the other hand, solving the splicing problem will also be complicated
for implementations, and for the specification as well.
-------