[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A better future
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!'
`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
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
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.
Opinionated, yes. Correct? Hmmm....