This page is part of the web mail archives of SRFI 17 from before July 7th, 2015. The new archives for SRFI 17 contain all messages, not just those from before July 7th, 2015.
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