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


Issue SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS Writeup

Issue:            SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS

References: SYMBOL-MACROLET, SPECIAL proclamation,

AUGMENT-ENVIRONMENT,

CONSTANTP, VARIABLE-INFORMATION

Related issues: Issue SYMBOL-MACROLET-DECLARE

Issue SYMBOL-MACROLET-SEMANTICS

Issue SYNTACTIC-ENVIRONMENT-ACCESS

Issue CONSTANTP-ENVIRONMENT

Issue CONSTANTP-DEFINITION

Category: CLARIFICATION

Edit history: v1, 15 Feb 1991, Sandra Loosemore

v2, 13 Mar 1991, Sandra Loosemore

Problem description:

Can a symbol-macro definition shadow a variable that has been

PROCLAIMed SPECIAL or defined as a constant using DEFCONSTANT?

Both SPECIAL proclamations and DEFCONSTANT definitions pervasively

affect the semantics of variable bindings. The question is whether a

symbol-macro binding of a symbol in the variable namespace is a

variable binding in this sense.

Note that issues SYMBOL-MACROLET-DECLARE and SYNTACTIC-ENVIRONMENT-ACCESS

require that an error be signalled if a SPECIAL declaration is supplied

for a name being bound as a symbol-macro.

There are two proposals, SHADOWING-PERMITTED and SIGNALS-AN-ERROR.

Proposal (SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SHADOWING-PERMITTED):

Clarify that a SYMBOL-MACRO definition of a symbol shadows any other

interpretation of that symbol as a variable, even if the symbol is

a keyword or has been PROCLAIMed SPECIAL or defined as a constant

using DEFCONSTANT.

Note that lexical shadowing of keywords and defined constants

requires the use of an environment argument with CONSTANTP (see issue

CONSTANTP-ENVIRONMENT). Clarify that if the first argument to

CONSTANTP is a symbol that is a keyword or globally defined as a

constant, CONSTANTP must return true only if that symbol is not

lexically shadowed by a symbol-macro definition in the specified

environment. Likewise, VARIABLE-INFORMATION returns :SYMBOL-MACRO

rather than :CONSTANT as its first value if the symbol is a keyword

or defined constant that has been lexically shadowed by a symbol-macro

definition in the specified environment.

Rationale:

This is a reasonable interpretation to some people.

Proposal (SYMBOL-MACROS-AND-PROCLAIMED-SPECIALS:SIGNALS-AN-ERROR):

Clarify that a SYMBOL-MACRO definition of a symbol that is a keyword

or that has been PROCLAIMed SPECIAL or defined as a constant using

DEFCONSTANT is not permitted.

Require SYMBOL-MACROLET to signal an error if any of the symbols being

bound as a symbol-macro are keywords, PROCLAIMed SPECIAL or defined as

a constant using DEFCONSTANT.

Require AUGMENT-ENVIRONMENT to signal an error if any of the symbols in

the :SYMBOL-MACRO alist are keywords, PROCLAIMed SPECIAL or defined as a

constant using DEFCONSTANT.

Rationale:

This is a reasonable interpretation to some people.

There is also a compatibility problem if CONSTANTP is permitted to

be sensitive to the lexical environment in which the form appears

(see the cost to users section below).

Examples:

#1: (defvar *foo* nil)

(symbol-macrolet ((*foo* t))

*foo*)

Under proposal SHADOWING-PERMITTED, this returns T.

Under proposal SIGNALS-AN-ERROR, an error is signalled.

#2: (defconstant frob "frob-constant")

(defmacro see-if-constant (form)

`(progn ,form ,(constantp form)))

(symbol-macrolet ((frob (funcall #'some-hairy-function)))

(see-if-constant frob))

Under proposal SHADOWING-PERMITTED, this returns T; note that

the call to CONSTANTP returns a value appropriate for the

null lexical environment but does not take into account the

local symbol-macro definition of FROB.

Under proposal SIGNALS-AN-ERROR, an error is signalled.

Current Practice:

Apparently shadowing is permitted in some implementations but not

others.

Cost to Implementors:

Proposal SHADOWING-PERMITTED is more work than SIGNALS-AN-ERROR

since all calls to CONSTANTP within the implementation need to be

examined to see whether an environment argument must be passed. This

also requires that something other than EVAL (like FUNCALL of ENCLOSE)

be used to compute the value of something that is CONSTANTP.

Cost to Users:

Many applications that now use CONSTANTP assume that the value it returns

is not sensitive to the lexical environment in which the form appears.

(Since CONSTANTP has not previously been specified to accept an

environment argument, it is hard to see how any other interpretation

could be made.) Proposal SHADOWING-PERMITTED represents an incompatible

change in this respect. All calls to CONSTANTP within user programs

would have to be examined to see whether an environment argument must

be passed. This also requires that something other than EVAL (like

FUNCALL of ENCLOSE) be used to compute the value of something that is

CONSTANTP.

Cost of non-adoption:

The language specification is unnecessarily vague.

Performance impact:

Probably none.

Benefits:

The cost of non-adoption is avoided.

Esthetics:

Seems to depend on who you talk to.

Most people seem to acknowledge that shadowing proclaimed specials and

defined constants with symbol-macros is abominable programming style.

Some people think disallowing shadowing complicates the language

unnecessarily by introducing yet another special case.

Some people think permitting shadowing complicates the language

unnecessarily by destroying the "globalness" of special proclamations

and constant definitions.

Discussion:

This issue was discussed on the x3j13 mailing list in May/June 1990.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.