SETF and sequence updater's return values

[Glenn S. Burke <GSB at MIT-ML>]

$0.02 worth:
    Since SETF seems to be constrained to operate as a macro, outside
of the domain of a smart compiler which could produce appropriate
optimizations, my personal feeling is that the returned value should
be undefined.  My own versions of setf, even the one written for
protosystem 3 years ago, have always had the macro SETV which was
like SETF but did guarantee the returned value.
    I think it is unreasonable to make SETF jump through hoops
constantly (and thereby tending to produce less optimal code) when the
potential exists to make the primitive updating form be more condusive
for use with SETF.  Thus, if SETF returns the stored value, the
updating function should return the value and take its args in the
proper order.  (If it does not, there should be an internal variant
which DOES, and the compiler should understand this and know how to
not bother returning the value when it is executed for effects.  And
most the time anyway, with things which are open-coded, the value will
already be in a convenient place.  Rather than, for every update which
will be open-coded, having the compiler recognize the immediate
re-access, as happens with (car (rplaca x y)) now.)