Related issues: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CHANGE, ADDITION
Edit history: V1, 02 Jan 1989, ???
V2, 12 Feb 1991, Sandra Loosemore
Defining macros including DEFTYPE, DEFSTRUCT, DEFCLASS, and
DEFINE-CONDITION are permitted to note type definitions at
compile-time in such a way that those definitions are visible only to
the file compiler and not to the evaluator. This can lead to
incorrect behavior in user code that deals with the type system, for
example in macro expansion functions. Such code needs to explicitly
indicate in some way whether it wishes to deal with the type system as
seen by the file compiler (the "remote environment"), or in the
Add an optional environment argument to TYPEP, SUBTYPEP,
UPGRADED-ARRAY-ELEMENT-TYPE, and UPGRADED-COMPLEX-PART-TYPE. If the
argument is NIL or not supplied, it defaults to the null lexical
environment and current global environment.
Clarify that &ENVIRONMENT may appear in the lambda-list of a DEFTYPE
form, as with DEFMACRO.
This is consistent with the mechanism used elsewhere to specify what
environment name/definition lookups should be performed in.
Chestnut's Lisp-to-C translator supports this mechanism.
Cost to Implementors:
Minor. Implementations that don't support the notion of "remote
environments" can ignore the environment arguments.
Cost to Users:
Minor. Users may have to be more careful about passing environment
Cost of non-adoption:
Programs that try to manipulate type information at compile-time will
break in some implementations.
The cost of non-adoption is avoided.
Looks OK to me.
Version 1 of this issue was lost. Version 2 is a completely new
Loosemore and Barrett support this proposal.
There may be confusion about why TYPE-OF does not need an
environment argument. Recall that compile-time type definitions made
by DEFSTRUCT, DEFCLASS, and DEFINE-CONDITION are permitted to be
partial or incomplete. Essentially, the only information that is
required at compile-time is that a name/type mapping exists and the
subtype/supertype relationships between all of the type specifiers.
On the other hand, the type must be fully defined before instances can
be created. If no instances can be created, then TYPE-OF has no need
to know about the type. TYPE-OF also has no need to know about type
specifiers defined with DEFTYPE.