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.
Dan Bornstein <danfuzz@xxxxxxxx> writes: > 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, The original draft mentioned (as an aside, not part of the proposal proper) how the proposal could work with a system that supports first-class locations. I took it out, since that made the proposal even more contentious and confusing. If you're curious: ** Explicit locations ** This SRFI does not propose making locations be first-class values. However, in this section I will sketch out how first-class locations can be added to Scheme (in a future SRFI) in a way that meshes well with this SRFI. The `location' form takes an lvalue and returns a location value: (define pa (location a)) We can think of `location' as similar to the C address-of operator `&'. The value `pa' is a "pointer" to `a'. To read the value stored in the location, we "de-reference" it. We could use a special de-referencing function, but I propose using procedure application: (define b (pa)) ;; same as: (define b a) Applying a location value yields the value stored in the location. Thus a location is a generalization of a thunk. To write the value stored in a location, we use the de-referencing operator (i.e. procedure application) as the location of a `set!': (set! (pa) 10) ;; same as: (set! a 10) (By the way: This is implemented in Kawa.) -- --Per Bothner per@xxxxxxxxxxx http://www.bothner.com/~per/