[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remote environments
- To: Gregor.pa@Xerox.COM
- Subject: Re: remote environments
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Mon, 13 Mar 89 12:40:42 CST
- Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Sandra J Loosemore <email@example.com>, Patrick Dussud <firstname.lastname@example.org>, "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>, email@example.com, firstname.lastname@example.org
- In-reply-to: Msg of Sun, 12 Mar 89 20:00 PST from Gregor.pa@Xerox.COM
- Sender: GRAY@Kelvin.csc.ti.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.
> 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?".
I don't see that we need to have separate classes for representing
things in the remote environment. The problem with closures is very
easily dealt with by performing compile-time remote-environment
definitions only for top-level forms. So I would say that yes there are
class objects in the remote environment and they look just like any
other class objects. Generic functions and methods are another matter
though; permitting compile-time instantiation of classes in the remote
environment should not be difficult, but it may not be very useful
without having the methods for that class available.
> > 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.
It sounds like there are two issues here: (1) what a
standard-conforming Common Lisp compiler is required to do, and (2) what
a portable program is able to do with the meta-object protocol features
provided. I was only addressing (1), but it sounds like you and Moon
have (2) in mind.