[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SETF-PLACES (version 1)
- To: firstname.lastname@example.org
- Subject: Issue: SETF-PLACES (version 1)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 22 Nov 88 19:49 EST
- In-reply-to: <8811152256.AA01215@bhopal>
I am not happy with this proposal, because I think it is excessively
complicated. I still prefer the SETF-FUNCTION-VS-MACRO proposal.
However, I would rather accept this kludge than not have CLOS at all, so
if X3J13 is adamantly against SETF-FUNCTION-VS-MACRO I will accept this
proposal. I would prefer to see X3J13 allowed to vote on both proposals
as alternatives, since it's possible that when they see this one they
would prefer the one they rejected before.
Note: I am not complaining about the writeup of the proposal, which
is quite clear, but about the substance of the proposal. I believe
the distinction between "specs" and "underlying names" is confusing
and unnecessary. Evidently that is a minority position.
A few additional comments on the details of the proposal. All of
these are easily corrected:
I believe that DEFUN should have syntax compatible with DEFGENERIC and
DEFMETHOD, for aesthetic reasons, and therefore the proposal should
specify that DEFUN will call UNDERLYING-NAME, just as DEFMETHOD does.
Once this is done, the first example can be simplified.
Similarly, LABELS and FLET should accept "specs", since GENERIC-LABELS
and GENERIC-FLET do. This would eliminate the non-portability of
the FLET of setf:3.bar.middle-ref example.
The get-setf-method-for-setf-functions example has parenthesis errors.
I did not check whether this proposal preserves the carefully worked out
rules about local functions and local macros from the earlier proposal.
I'll assume that it does.