I'm sorry I've been on the sidelines for this proposal, until now,
basically because I believe the SRFI is sound and didn't notice any
on-topic discussion worth adding to.

I am *strongly* in favor of generalized set! and pretty much agree with Per
as to the reasons why, although I don't quite agree with the proposed
underlying mechanism. I'm much more in favor of reifying locations
(lvalues, cells, whatever you want to call them) and, for that matter,
environments (although that's probably better suited to be in a separate
SRFI), and expecting the usual optimizations to elide their usage as
appropriate. That seems much more in line with "Scheme thinking" to me than
rewriting calls with extra arguments.

Just to reiterate what Per has said: There is a nice economy of concepts
when you get to collapse, on one axis, all of these into one concept of
"modifying a location":

    set! set-car! set-cdr! string-set! vector-set!

and on another axis, all of these pairs into a concept each of what
location they denote:

    car        set-car!
    cdr        set-cdr!
    string-ref string-set!
    vector-ref vector-set!

The nail in the coffin for me is that set! already has a double meaning (or
possibly triple, depending on your way of dicing up the universe) of
set-a-global-location and set-a-lexically-scoped-location (and possibly
dividing that into lexically-scoped-and-transient and
lexically-scoped-and-closed-over).

If I were trying to design a Scheme-like language but didn't have backward-
compatibility as a concern, I wouldn't even bother having set-car! et al be
part of the language. They've always struck me as inelegant and
superfluous. (That is, pretty much since day one of having been exposed to
Scheme, I've wondered why the RNRS authors didn't opt for a set! that was
more like CL setf rather than setq.)

Furthermore, there will be an opportunity (which I believe Per pointed out
in his original SRFI) to right a wrong where there is an asymmetry in R5RS
where there are a lot of getters without corresponding setters (most
notably, cxxr..cxxxxr). These can all be added to the language (library,
whatever) via the set! extension and simultaneously *simplify* the mental
model of the language that a programmer maintains.

Per writes:
>While the srfi process allows for srfis that are controversal and don't
>have consensus, at this stage it seems kind of pointless to pursue it.

I believe it should be pursued, and I consider the whole thread of
discussion of the goodness/badness of generalized set! to be off-topic, and
I feel a bit dirty having now contributed to the noise. The fact is that
there are already Scheme variants that have generalized set!, various
implementations disagree about the details, and this SRFI may be able to
generate a useful consensus thereby making many real world Scheme
programmers much happier in the long run. Without consensus, there will
*still* be Scheme variants that have this functionality, and they'll just
go on differing in semantically insignificant details.

Thanks for listening.

-dan