Re: Redefinition of Common Lisp Functions

[Jim Kempf <kempf%hplabsc@hplabs.HP.COM>]

I guess I need to clarify my comments. I see two competing needs here:

1) On the one hand, system vendors and applications distributors 
require the option of not allowing users to redefine Common 
Lisp functions. Allowing users to do so makes supplying safe,
good quality software difficult because regression testing becomes next to
impossible.

2) On the other, researchers and people prototyping advanced
applications might want to modify the semantics of certain
Common Lisp functions for experimental purposes.

It seems to me that protection of functions could be included
in postdevelopment packaging, perhaps by setting a switch or
on a package by package basis. The method I used to modify EQ, etc. in
CommonObjects may, in fact, be the desired one: shadow those
Common Lisp functions in the packages where the modified
functions are desired with noninterned symbols having the
same print names as the functions. Attempts to directly redefine
the functions may cause an error to be signalled.
This technique would require no changes in the standard, or
the standard could be toughened up to require that an error
be signalled, as long as it is not toughened to the point
where shadowing Common Lisp functions is an error.

With regard to Moon's comments about the CLOS:

>    3. (More constrained redefining) Presuming the CLOS, which of the
>    predefined Common Lisp functions should be specializable for
>    user-defined classes? How should such specialization affect the rest of
>    the behavior of Common Lisp?
>
>The working group for defining the proposed object-oriented programming
>standard ("CLOS") has thought about this just enough to realize that it
>is complex and difficult.  The group, or someone, will have to do more
>work in this area, but it's not going to be easy.

I agree. There are a core set of functions which object-oriented
application developers usually say they want to be specializable,
but, considering the wide variety of Common Lisp implementations
out there, it may be difficult to provide them without stepping
on someone's toes.

		Jim Kempf	kempf@hplabs.hp.com