[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: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 13 Mar 89 12:42:58 MST
- Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <dussud@lucid.com>, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
- In-reply-to: Gregor.pa@Xerox.COM, Mon, 13 Mar 89 10:22 PST
> Date: Mon, 13 Mar 89 10:22 PST
> From: Gregor.pa@Xerox.COM
>
> We must decide so that users who define their own metaobject classes can
> know under what conditions those classes will be instantiated.
Perhaps my ignorance is showing, but I didn't think that chapters 1 &
2 gave users enough information to define their own metaobject classes
anyway. If making this statement is only of interest for users of the
part of CLOS that is specified in chapter 3, I don't think we absolutely
positively need to say anything about this now. Frankly, I question
whether the metaobject protocol is stable enough that we should even
*try* to do so now.
> I believe it is possible to take a minimal stance on what we specify.
> One such workable minimal stance is to say that no portable metaobject
> class will ever be instantiated in the remote environment. In this
> scheme, the implementation could instantiate its own metaobjects in the
> remote environment, and it could instantiate placeholders for user
> metaobjects as well. This would make it possible to do the kind of file
> compilation we all know and love when doing normal programming. Only
> portable `compilers' would have to use the load, then compile approach.
I guess part of the problem I'm having is understanding what this
implies for normal user code. I think we ought to say something in
the standard that your average ignoramus like me can understand, about
how to arrange programs so they will compile correctly. The current
writeup does that, your statement here doesn't.
Is there anything in the MINIMAL proposal that is fundamentally
incompatible with this stance? I can see that wanting classes to be
instantiable at compile-time (as in proposal NOT-SO-MINIMAL) would
imply that the DEFCLASS macro causes some kind of metaobject to be
created at compile time. However, it would still be possible to do
without distinguished "remote" metaobjects by having DEFCLASS make the
class fully defined in the compile-time environment.
-Sandra
-------