[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: where is srfi-17 going?

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/