Related issues: Issue LISP-SYMBOL-REDEFINITION
Category: CLARIFICATION, CHANGE
Edit history: V1, 05 May 90, Sandra Loosemore
V2, 29 May 90, Sandra Loosemore (forgot one)
The description of PPRINT-EXIT-IF-LIST-EXHAUSTED and PPRINT-POP
in issue PRETTY-PRINT-INTERFACE specifies that "an error message
is issued" if either of these constructs are used anywhere other
than syntactically nested within a call on PPRINT-LOGICAL-BLOCK.
It is not clear whether this means "an error is signalled" or
"a message is printed", or whether this situation must be
detected at compile time or at run time.
This is actually a more general problem, since there are other
constructs in the language that have similar scoping requirements:
notably LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and NEXT-METHOD-P.
The error behavior of all of these constructs when they are referenced
outside the lexical scope where their behavior is defined ought
to be made consistent, as should the matter of whether they
are permitted/required/not allowed to be globally FBOUNDP.
This issue incorporates items #2 and #23 from Loosemore's list.
This proposal affects the constructs PPRINT-EXIT-IF-LIST-EXHAUSTED,
PPRINT-POP, LOOP-FINISH, CALL-METHOD, CALL-NEXT-METHOD, and
NEXT-METHOD-P, which are referred to as "lexically-scoped operators".
(1) Change the descriptions of lexically-scoped operators to
state that any attempt to invoke the operator outside of the
lexical scope where its behavior is defined has undefined
(2) Clarify that it is unspecified whether function names that
are defined by the standard as lexically-scoped operators have
global function or macro definitions (i.e., are FBOUNDP).
(3) Clarify that the restrictions on redefinition or shadowing
of symbols in the COMMON-LISP package (originally stated in issue
LISP-SYMBOL-REDEFINITION) are the same for symbols that define
lexical operators as for symbols that are globally defined as
This gives maximum freedom to implementors and avoids having to
deal with sticky issues about whether errors are detected at
compile or run time, etc.
I suspect it is fairly common practice to define these operators
using MACROLET (etc) and provide a global definition that
signals an error if it is invoked.
Cost to Implementors:
Cost to Users:
Cost of non-adoption:
Part of the language specification remains imprecise,
inconsistent, and confusing.
The language specification is made more precise, consistent,
and less confusing.
Treating all of these guys uniformly is better than having them
all specify something slightly different with regard to their
The situation with the DECLARE special form is related but not
entirely analogous, so it has been left out of this proposal.
From a purely abstract point of view, DECLARE is not a special form
at all but simply a syntactic marker like LAMBDA, and the only
reason for defining it as an operator is to facilitate diagnostics
about misplaced declarations.