Re: Redefinition of CL Functions

[sears%wrs.DEC@decwrl.DEC.COM]

Are there cases where shadowing COMMON LISP symbols, then giving the
shadowing symbols new definitions does not provide sufficient capability
to layer extensions on a COMMON LISP implementation?

I built a layered language for instrumentation, and used shadowed symbols
to provide the new definitions. This works fine in VAXLISP.

It was necessary to provide type definitions for symbols used as both
a function and a type (LIST, STRING, etc), and to provide DEFSETF
expanders for the new names.  Are there other known problems?

This approach is well defined because you know which definition you are
using (It depends on the package in effect when the file is read or compiled),
and it is straightforward to reference the standard definition if it is
needed.  It also works with our compiler, which does not optimize
any of the new definitions, since it doesn't recognize any of the
new functions.

Incidentally, VAX LISP gives a warning message when you try to redefine
a built-in COMMON-LISP function.

/wrs