[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SETF-SUB-METHODS (Version 5)
- To: cperdue@Sun.COM, masinter.pa@Xerox.COM
- Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Tue, 10 Jan 89 10:41:42 PST
- Cc: cl-cleanup@sail.stanford.edu
> In your ballot, you said:
>
> This does not seem to be the "right" choice of semantics, and I
> believe that the presentation of the proposal needs substantial work
> even if it is "right".
>
> Can you help us? in what way is it wrong? what might be better? what
> cases are unclear that we need to clarify?
Right. I didn't feel I could do justice to this issue before the January
X3J13 meeting.
Perhaps these comments will be of some use:
Consider example 6.
(setq s (setq r (list 'a 1 'b 2 'c 3)))
(setf (getf r 'b) (progn (setq r nil) 6))
r ==> (b 6)
s ==> (a 1 b 2 c 3)
I find the SETF expression naturally maps to:
(setf r (put-plist r 'b (progn (setq r nil) 6)))
where put-plist is a destructive function on lists in the usual
Common Lisp style, where it must be used for its value.
With this expansion,
r ==> (a 1 b 6 c 3)
s ==> (a 1 b 6 c 3)
Perhaps I am wrong, but I think others will realize that they find
this more natural also.
Concerning the statement of the proposal, it seems to me that 3
half-page discussions -- one for CHAR-BIT, one for GETF, and one
for LDB and MASK-FIELD, is far too much to have to say about such
a fine point in the language.