[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I attempted to incorporate the extra cases Moon pointed out (on 13 Oct)
and reorganized the proposal a bit to avoid some of the circumlocutions
involved in saying "the consequences of blah blah ...  blah are undefined."

References:    Cleanup issue PACKAGE-CLUTTER
		CLtL pp 67-69 Defining named functions
Category:      CLARIFICATION
Edit history:  Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
               Masinter, Version 2, 7-Oct-88
               Masinter, Version 3,  7-Oct-88, fix typos
               van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
               Masinter, Version 5, 22-Nov-88, add more cases
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't 
solve the general problem of redefining system functions.

This proposal uses the phrase "the consequences are undefined" in the
sense that implementations may signal an error, or other undefined behavior
may ensue, and attempts to specify that user programs generally cannot
portably modify the behavior of the symbols in the LISP package.

For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are

Specify that the consequences of performing any of the following
operations are undefined:

* redefining as a function or macro any of the functions,
macros, or special forms defined in the LISP package;
* lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package;
* attempting to rebind any symbol in CL defined as a constant;
this covers binding as with LET or LAMBDA, assignment
as with SETQ or SETF, or using MAKUNBOUND;
(implied by CLtL p. 69)

* defining type-specifiers as with DEFTYPE, DEFSTRUCT, or
DEFCLASS, any of the built in type specifiers, classes;

* defining or redefining SETF macros or functions of any
of the functions, macros or special forms that have specified
SETF behavior, using either DEFSETF or DEFINE-SETF-METHOD
(or with DEFUN if the proposal under SETF-FUNCTION-VS-MACRO
is adopted);

* applying TRACE to any function in the LISP package.

No other restrictions are placed on users attaching definitions
on symbols in the LISP package; for example, a user program

The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....") 
			(OPEN filename :direction direction)))
    (with-open-file (x "frob" :direction ':output) 
		(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
might signal an error.
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp. 
Cost of non-adoption:
Continued questions.
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble. 
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however. 
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.