As we near the end of the discussion period for srfi-17, I've got to
wonder what its final state is going to be. There seem to be two solid
camps: Those who find it objectionable because it conflates the notion
of mutating bindings and mutating values, and those who like it for
the same reasons. Some alternatives for making it more palatable have
been suggested by the objectors (using an alternative name, full
reification of locations), and Andy Gaynor has just posted an
implementation of a system which appears to achieve similiar goals.

I would like to strongly suggest that this srfi be withdrawn and
re-presented as a more straightforward attempt to reify locations for
the following reasons:

1 - This is a stated goal of the srfi itself, even though Per has
    denied it. From the abstract:

	`This is a proposal to allow "functions that reference a
	location" to be used as the first operand of set!'

			and

	`Many programming languages have the concept of an lvalue. that
	is an "expression" that "evaluates" to a location, and which
	can appear on the left-hand-side of an assignment'

2 - After much grovelling over the formal semantics in R5RS, I can say
    that bindings are *not* mutated by anything in that denotational
    specification, locations are. However, denotational specifications
    have the disadvantage that they over-specify the semantics of the
    language in question and strongly suggest a particular
    implementation. Hence R5RS has second-class locations in it's
    formal spec, which I would like to see become first-class. A good
    first-class location SRFI could be a testbed for an RnRS with the
    feature.

3 - There is no obvious or natural correspondence between a procedure
    call form and the modification of a particular location. By having
    a location type such a correspondence can be established and
    clearly reasoned about.

4 - It is not 'in the spirit of Scheme' to have extra information
    about values squirrelled away somewhere in the run-time
    system. This is why R5RS doesn't have putprop/getprop (although
    many Schemes do provide it). As SRFI-17 stands, such shenanigans
    are required for its implementation unless locations are reified
    in the implementation.

5 - The fact that setters are of purely global scope is really
    unacceptable in a lexically scoped language. I have not really
    thought through this issue yet. I include it because of the
    nearness of the end of the discussion period. That setters can be
    arbitrarily changed in the global scope opens a wide door for
    pernicious bugs.

6 - Syntactic abstractions which would be supported by the SRFI-17
    mechanism can be simply transformed into procedural abstractions
    with reified locations. Given that there is a significant Scheme
    sub-community which doesn't really like macros at all, they would
    also be better served by a reified location scheme.

In summary, to achieve the goals of SRFI-17, SRFI-17 is the wrong way
to do it. The right thing (TM) is to reify locations.

david rush
--
Opinionated, yes. Correct? Hmmm....