[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: where is srfi-17 going?
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.)