"Written Responses" to CLOS 88-002: SETF Functions

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

    Date: Wed, 27 Apr 88 19:10:14 PDT
    From: Jon L White <edsel!jonl@labrea.Stanford.EDU>

    re: If X3J13 has adopted setf functions, I agree that the CLOS spec does not
	need to discuss them.  If X3J13 is still dithering, I think the writeup
	should stay in the CLOS spec.  If X3J13 has rejected setf functions, then
	we have a problem.

    SETF functions foundered on issues having nothing to do with function specs.
    I say, "foundered", not meaning that they were rejected, but that substantial
    issues were raised (mostly by Sandra Loosemore), and the discussion didn't
    come to completion by the end of the day.

    You missed the "Definitions Specs" presentation; there seemed to be
    unanimous approval for continuing that proposal.  Even if there is 
    continuing objection/discussion (and I don't think there will be) to the 
    particulars of the "setf functions" semantics, there doesn't seem to be 
    objections to "function specs".  

I hope we're going to vote on SETF functions in June so we can get this
out of the way.

    I believe that most of Sandra's objections were met by our collective 
    responses that day.  For example, she wanted to know why their syntax
    differed from that suggested by DEFSETF -- why the "new value" was the
    first argument rather than the last.  We replied that it is necessary to 
    be able to discriminate on the class of the "new value", and there is
    no easy syntax for defining a method that discriminates on the last
    argument rather than the first several.

This is wrong.  The real reason is that Common Lisp does not provide a
lambda-list syntax for describing a function that takes a required argument
following an optional argument.  Thus if new-value was the last argument,
it would be impossible for setf functions to have optional arguments, which
would be a serious hindrance.  We considered schemes where the new-value
argument came between the required arguments and the optional arguments,
but rejected them as kludgey and error-prone.

    However, under no circumstances can one justify leaving a "fix up" of
    CL in the CLOS spec.  At best, CLOS should have an appendix explaining
    any non-standard assumptions about the CL language --  an appendix which
    itself isn't an integral part of the spec, but only an aid for those
    who are not yet familiar with other X3J13 activity.

I think the fixup of CL is only in the CLOS subcommittee report, not in
the CLOS specification as proper (which does not yet exist).  However,
I like your suggestion that the CLOS subcommittee report should be
reorganized to put things that are proposed to become part of Common Lisp,
rather than part of CLOS proper, into something labeled an appendix.