[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: LISP-SYMBOL-REDEFINITION (Version 2)
- To: email@example.com
- Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 2)
- From: masinter.pa@Xerox.COM
- Date: 7 Oct 88 16:24 PDT
down to the wire, but if you have a chance, you might want to glance at
this before I send it out next time around...
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Edit history: Masinter, Version 1, 17-Sep-88
Masinter, Version 2, 7-Oct-88
CLtL allows the redefinition of functions exported from other packages.
Unexperienced programmers may redefine a system function unintentional
may result into an inconsistent state of the system and cause to abort.
has happened, for example, with a beginner follows an introductory
book where an exercise asks to define a function MAKE-LIST. After the
redefinition of MAKE-LIST the system crashs without returning a message
function has been redefined.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
Following the proposed definition of "results are unspecified", this means
implementations may signal an error, or other unspecified behavior may
ensue. 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
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 unspecified; for example, the macro expansion of with-open-file might
to the OPEN function and might not.
(defun car (x) (cdr x))
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
their own package, possibly shadowing the name.
Many Lisp environments have some mechanism for warning about redefinition
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 results are unspecified.
allows and encourages implementors to check for such redefinition, but does
Cost to Users:
This proposal clarifies that implementations are free to check for a
that they might not have before, and may clarify that some current user
This issue frequently arises. Adopting this proposal would clarify a
source of question about Common Lisp.
Cost of non-adoption:
Disallowing all redefinition is the simplest way of disallowing the ones
really are trouble.
There have been various proposals for allowing users to extend the
mechanism to their own macros, functions, packages. These proposals seem
they are environment issues and not language ones, however. For example,
you might have a list *REDEFINITIONS-RESTRICTIONS* or
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.