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.
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....