Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Category: CHANGE, ADDITION
Edit history: v1, 12 Feb 1991, Sandra Loosemore
v2, 15 Feb 1991, Sandra Loosemore (comments from KAB)
v3, 13 Mar 1991, Sandra Loosemore
It is permitted for DEFCONSTANT to note the definition of the constant
at compile-time in such a way that the definition is visible only to
the file compiler and not to the evaluator. This can lead to
incorrect behavior in user code that uses CONSTANTP, for example in
macro expansion functions. Such code needs to explicitly indicate in
some way whether it wishes to deal with constant definitions in the
environment seen by the file compiler (the "remote environment"), or
in the current environment.
Add an optional environment argument to the function CONSTANTP. If
the argument is NIL or not supplied, it defaults to the null lexical
and the current global environment.
CONSTANTP may use the environment to determine whether a symbol has
been globally defined as a constant (as with DEFCONSTANT).
Unless at least one of proposals CONSTANTP-DEFINITION:INTENTIONAL,
SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED is accepted,
the value returned by CONSTANTP may not depend on lexical information
in the environment.
It solves the problem in a way that is consistent with the way it is
handled in other places in the language.
Chestnut's Lisp-to-C translator implements this proposal.
Cost to Implementors:
The cost of adding the environment argument is quite small.
In implementations that do not support remote environments, the argument
can simply be ignored.
Cost to Users:
The behavior of existing programs that call CONSTANTP without an
environment argument will not be affected. However, there is some
motivation for users to change calls to CONSTANTP to pass an environment
argument where appropriate, since in implementations that do support
remote environments, calling CONSTANTP without an environment argument
might result in NIL being returned for some things that could otherwise
have been detected as constant.
Cost of non-adoption:
Some programs will work incorrectly.
The cost of non-adoption is avoided.
Looks OK to me.
If proposal SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED
is accepted, CONSTANTP needs to accept an environment argument so that
it can detect when a defined constant has been lexically shadowed by a
If proposal CONSTANTP-DEFINITION:INTENTIONAL or ADD-ARGUMENT passes,
CONSTANTP needs to accept an environment argument so that it can perform
the additional kinds of analysis these proposals permit (such as
macroexpansion) in the correct lexical environment.
Proposal CONSTANTP-ENVIRONMENT:ADD-ARG only extends the syntax of
CONSTANTP and permits CONSTANTP to use *global* information in the
environment. Issues SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS and
CONSTANTP-DEFINITION include proposals that would require that
CONSTANTP also be sensitive to *lexical* information in the environment.
The costs to users and implementors that this would involve are
potentially much higher, but are more properly costs associated with
those other proposals, not CONSTANTP-ENVIRONMENT:ADD-ARG.