[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue CONSTANTP-ENVIRONMENT Writeup

Issue:               CONSTANTP-ENVIRONMENT

References: CONSTANTP

Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

DEFCONSTANT-SPECIAL

SUBTYPEP-ENVIRONMENT

SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS

CONSTANTP-DEFINITION

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

Problem description:

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.

Proposal (CONSTANTP-ENVIRONMENT:ADD-ARG):

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,

CONSTANTP-DEFINITION:ADD-ARGUMENT, or

SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED is accepted,

the value returned by CONSTANTP may not depend on lexical information

in the environment.

Examples:

???

Rationale:

It solves the problem in a way that is consistent with the way it is

handled in other places in the language.

Current Practice:

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.

Performance impact:

Minor.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Looks OK to me.

Discussion:

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

symbol macro.

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.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.