SETF-FUNCTION-VS-MACRO (Version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 23 Oct 87 14:30 PDT
    From: Gregor.pa@Xerox.COM

    In particular, I would like it to be the case that however we finally
    write this up, we make it clear that in many cases (not all cases)
    defsetf is now obsolete.  I believe that having programs which don't
    need to use defsetf avoid doing so will considerably simplify the Common
    Lisp evaluator as seen by those programmers.  I believe that teaching
    the style of SETF which doesn't use defsetf (long) before the style
    which does will make it more understandable to students.

I agree with this, but I think "obsolete" might be too strong a word.
What we're saying is that using setf functions instead of setf macros
wherever you can is good programming style.  I think the analogy to regular
macros is compelling.  In the old days people used to over-use macros,
or even worse fsubrs, where they could just as well have used functions;
eventually it was widely realized that this was a bad idea, and that
macros should only be used where you are actually trying to do syntax
extensions.  This didn't mean macros were obsolete, it just meant that
people better understood when it was good programming style to use them.

In the CL-Cleanup proposal form, this would go in the Benefits section.

	Date: Thu, 15 Oct 87 20:21 EDT
	From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	I have no problem with this proposal, except for the notion that the
	name of the setf-function associated with FOO should be a list, (SETF
	FOO).

    Of course another solution to this problem would be to say that the
    function name for the "setf function" for FOO is |SETF FOO|.
    Specifically, instead of having the mapping:

       package::foo  ==>  (setf package::foo)
       package::foo  ==>  package::|SETF FOO|

    Of course |bar| would become |SETF bar|.

    The advantage of this is it doesn't require introducing list function
    specs.

Right.  The problem is that "package::" above hides a multitude of
sins.  How is (defun (setf car) (new-car cons) (rplaca cons new-car) new-car)
to be written in your proposal?  There is a separate symbol |SETF CAR|
in every package, unless this (and all possible others) is pre-interned
in the Lisp package.  I think what this shows is that if we want to derive
one object from another object, in Lisp doing this with list processing
works a whole lot better than doing it with string processing.

It might be worth putting this little digression into the Discussion section.

    If we do introduce list function specs, we have to decide wether they
    can appear as the car of a form (I assume they can't).

The latest version states that they can't.