[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue SYNTACTIC-ENVIRONMENT-ACCESS
- To: email@example.com (Sandra J Loosemore)
- Subject: Re: Issue SYNTACTIC-ENVIRONMENT-ACCESS
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Thu, 23 Feb 89 20:40:06 CST
- Cc: "Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@SAIL.STANFORD.EDU, eb@LUCID.COM
- In-reply-to: Msg of Thu, 23 Feb 89 10:17:49 MST from firstname.lastname@example.org (Sandra J Loosemore)
- Sender: GRAY@Kelvin.csc.ti.com
> > ENVIRONMENT-PROPERTY env name property &optional default
> > This function and its SETF method allow the association of arbitrary 'global'
> > properties with names. An environment can be thought of as having a local
> > property list associated with any name, and this function provides access to
> > that property list. The association between names and property lists uses
> > EQUAL to match names.
> I think this particular item needs more rationale to support it. I
> gather that this is supposed to be the internal mechanism by which
> CLOS hangs information about the class structure off the environment?
> Why does this need to be generalized -- what is wrong with having
> FIND-CLASS be the primitive accessor for this kind of information?
There is precedent for this -- the MIT Lisp Machine system used by TI
and LMI provides a pair of functions called GETDECL and PUTDECL which
can be used to retrieve and store properties in the compile-time
environment. The main difference is that the compiler environment is
implicit rather than being passed in as an argument. I don't know how
many programmers actually use this feature, but since it needs to exist
for the compiler's own use, I don't see any harm in defining a standard
interface for it.