[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: SETF-SUB-METHODS (Version 5)



> 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.