Issue: SETF-SUB-METHODS (Version 5)

[Jon L White <jonl@lucid.com>]

re: 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)))

This is the conceptual bug you make if you fail to notice the
distinction between evaluating the "value-producing subforms"  and
"reading the value" out of the generalized location.  The top part
of the second page of the proposal tries to warn the reader about
this by saying:
   "``reading the value'' of a generalized variable reference is not
    part of the series of evaluatons that must be done in left-to-right
    order."
Of course, Test Case 6 is a worst-case pun of sorts, since "reading
the value" is exactly the same set of computer instructions as
"evaluating the value-producing subforms".  It is a malice-aforethough
worst-case test, just to illustrate the point.  [Incidentally, these are 
Test Cases rather than Examples.]

We are fully aware that this is (A) a "fine point" and (B) a very
detailed point.  However, failure to specify the details correctly will
lead to an incorrect implementation, especially in regard to the Test
Case 2.  A previous proposal had that flaw, and we didn't notice until
actually coding it up and observing some previously working code
breaking.  At least it isn't three pages of dense specification, since
most all of the three parts are isomorphic.  But someone on the
subcommittee objected to a specification that was loosely worded like
"and similarly for CHAR-BIT and LDB etc.".


Since this is a Clarification (not an addition or change) of what we 
think CLtL already says or implies, then a "No" vote is not nearly so
meaningful as an alternate clarification.  I think you will find it
is not so easy a task to specify a general rule for sub-form semantics
if you base it only on the more limited reading of Test Case 6.
Test Case 2 must be accommodated also.



-- JonL --