[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SAIL.STANFORD.EDU
- Subject: "Redefining" functions
- From: Hvatum@MIT-MULTICS.ARPA
- Date: Tue, 21 Apr 87 01:02 EDT
From: Steve Bacher (Draper Lab)
From: Jim Kempf <kempf%hplabsc at HPLABS.HP.COM>
Subject: Re: Redefinition of Common Lisp Functions
To: common-lisp at SAIL.STANFORD.EDU
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
2) On the other, researchers and people prototyping advanced
applications might want to modify the semantics of certain
Common Lisp functions for experimental purposes.
I had in mind a third need:
3) User specifying a function whose name happens to conflict with the
name of an already existing LISP function, not with the intent of
changing the behavior of the LISP function, but with the purpose of
defining a new function for use with that user's code only.
The user may not know that the function already exists, and therefore
will not qualify or shadow it wrt the package system or use FLET.
Even if a non-used function name is chosen, who is to say that CL
version II won't chew up that name and (depending on the implementation)
break this guy's system?
Conceivably the LISP system could be compiled so that calls to any
built-in CL functions are done in a special "fast-call" way which
bypasses actually referencing the function cells of those symbols.
(Especially true for inline code.) Of course, this has the effect
of making CommonLOOPS-style function-redefining impossible, but
there ought to be other solutions to that problem. Which is the
subject of another discussion that I don't feel qualified to