[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.)
	--Per Bothner
per@xxxxxxxxxxx   http://www.bothner.com/~per/