>Barry Margolin <bar...@bbnplanet.com> writes:

>> That's only feasible if you have control over the code that will be calling
>> the function.  The impression I got from his example is that this code is
>> already written and presumably unchangeable, which is why he wants to
>> change what happens when it calls certain functions.  If you had access to
>> the source code you could simply remove the call to ERROR, or have it call
>> a different function that calls ERROR conditionally.

>that's exactly right.  I was making a call to a function that is provided by
>LW.  It was returning an error for an unknown reason, and I wanted a
>work-around.  Of course, I didn't have access to the source, so I setf'd the
>function definition of 'error to return nil no matter what, and then the
>funtion call worked just fine.

>Basically, the behavior I wanted was that which happens in Emacs Lisp.  I
>wouldn't use it in real code; maybe just at the prompt.  Something like what
>Barry wrote would work.  I just wanted to know if there was a standard way
>about it.

>> Note one thing about my solution and the ERROR example: the consequences of
>> redefining built-in functions is not defined in Common Lisp.  A CL
>> implementation is permitted to generate inline code for built-in functions,
>> so redefining ERROR might not have any effect.  It could also invoke ERROR
>> internally, at times that you didn't expect (presumably depending on
>> internal condition handlers to hide this from you), so redefining ERROR
>> (even temporarily) could cause unexpected malfunctions.

>This is really a shame.  I understand that there's a performance issue here,
>and why there might therefore be a distinction between built-in functions and
>those defined by the user.  But I don't like it.  At the same time, however,
>the ability to inline code is important, and I don't know what the compiler
>would have to do in order to make inlined code safe when you setf something
>like (fdefinition 'error).