[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"Written Responses" to CLOS 88-002: SETF Functions
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.