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.