From: Vassil Nikolov
Subject: undoing DEFSETF
Date: 
Message-ID: <19980506152736.28688.qmail@nym.alias.net>
It would be nice if SETF-EXPANDER-FUNCTION, and in particular
(SETF (SETF-EXPANDER-FUNCTION ...) NIL) had been included
in the language.

I needed to undo the effect of DEFSETF when the expander I
defined turned out to be wrong, and then decided to use
(DEFUN (SETF ...) ...) instead.  There seemed to be no
other way to do that except (the somewhat kludgy)

  (defsetf foo (...) (new-value)
    `((setf foo) ,new-value ...))

after saying (DEFUN (SETF FOO) ...).

(I admit that I actually restarted Lisp.)

Best regards,
Vassil.

From: Kent M Pitman
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <sfw1zu75nav.fsf@world.std.com>
"Vassil Nikolov" <········@math.acad.bg> writes:

> It would be nice if SETF-EXPANDER-FUNCTION, and in particular
> (SETF (SETF-EXPANDER-FUNCTION ...) NIL) had been included
> in the language.

I agree.

> I needed to undo the effect of DEFSETF when the expander I
> defined turned out to be wrong, and then decided to use
> (DEFUN (SETF ...) ...) instead.  There seemed to be no
> other way to do that except (the somewhat kludgy)
> 
>   (defsetf foo (...) (new-value)
>     `((setf foo) ,new-value ...))

If this worked, it's non-conforming.  You want

  (defsetf foo (...) (new-value)
    `(funcall #'(setf foo) ,new-value ...))

> after saying (DEFUN (SETF FOO) ...).
 
That's not needed.  If there'd not been a SETF expander for FOO,
it would have generated the above FUNCALL whether (SETF FOO) was
fdefined or not.

> (I admit that I actually restarted Lisp.)

I probably would have, too.  I'll note your request for a 
SETF-EXPANDER-FUNCTION as a possible future change.
From: Kelly Murray
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <nmsomntao5.fsf@charlotte.i-have-a-misconfigured-system-so-shoot-me>
Yes, undefsetf should be defined.
I also believe even more important is for CLOS
to have an undefmethod.

-Kelly Murray  ···@franz.com
From: Dan Higdon
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <sf441.656$K4.654793@news.giganews.com>
Kelly Murray wrote in message ...
>Yes, undefsetf should be defined.
>I also believe even more important is for CLOS
>to have an undefmethod.
>-Kelly Murray  ···@franz.com

I'm kinda new to this CL thing (more scheming
in my past), but can't you just unintern the
symbol for the generic function?  If you're
really done with the function, the garbage
collector should take care of it as needed.

Or did you mean that you want to remove
a method *from* a generic function?  Yeah,
I can see where that might be useful, instead
of having to kill-n-compile all the other
methods.  I can see why the compiler might
not like removing methods though - it might
foul up some fancy dispatching tables.

----------------------------------------
····@charybdis.com
"Throwing fire at the sun"
From: ·······@uwaterlooREMOVETHIS.ca
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <3551ebfd.13613094@news.uwaterloo.ca>
On Wed, 06 May 1998 21:04:24 GMT, "Dan Higdon" <····@charybdis.com>
wrote:
>Kelly Murray wrote in message ...
>>I also believe even more important is for CLOS
>>to have an undefmethod.
>
>Or did you mean that you want to remove
>a method *from* a generic function?  Yeah,
>I can see where that might be useful, 

Isn't that what remove-method is for?



	Kevin
From: Steven M. Haflich
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <35523C12.90248527@franz.com>
Kelly Murray wrote:

> Yes, undefsetf should be defined.
> I also believe even more important is for CLOS
> to have an undefmethod.

Perhaps, but the existence of the standard operators FIND-METHOD,
REMOVE-METHOD, plus the MOP function INTERN-EQL-SPECIALIZER, make
undefmethod fairly easy to write in a portable way.  There is no
portable way to remove a defsetf, although the clever redefinition
discussed previously has the same effect.
From: Vassil Nikolov
Subject: Re: undoing DEFSETF
Date: 
Message-ID: <19980507170749.4959.qmail@nym.alias.net>
On Wed, 6 May 1998 10:20:08 -0700, 
Kent M Pitman  <······@world.std.com> wrote in comp.lang.lisp:

>"Vassil Nikolov" <········@math.acad.bg> writes:
>
(...)
>> I needed to undo the effect of DEFSETF when the expander I
>> defined turned out to be wrong, and then decided to use
>> (DEFUN (SETF ...) ...) instead.  There seemed to be no
>> other way to do that except (the somewhat kludgy)
>> 
>>   (defsetf foo (...) (new-value)
>>     `((setf foo) ,new-value ...))
>
>If this worked, it's non-conforming.  You want
>
>  (defsetf foo (...) (new-value)
>    `(funcall #'(setf foo) ,new-value ...))

Thank you for the correction.  As I wrote, I didn't actually
do that (but restarted Lisp), so I was just sketching the only
solution I could think of for the case when restarting is not
an option.


>> after saying (DEFUN (SETF FOO) ...).
> 
>That's not needed.  If there'd not been a SETF expander for FOO,
>it would have generated the above FUNCALL whether (SETF FOO) was
>fdefined or not.

Yes, right; but there *was* a SETF expander, the bad one, and I
had to get rid of it, and further, I wanted to use (SETF FOO)
instead of DEFSETF for the second try.

(...)
>I'll note your request for a 
>SETF-EXPANDER-FUNCTION as a possible future change.

Thank you.

Best regards, Vassil.