Standard pair procedures already accept immutable pairs in the form of
datum literals.
Literal pairs, as I will call them (as distinct from ordinary pairs and ipairs), are immutable only in the sense that it is an error to mutate them. However, implementations *may* allow their routine mutation: Cyclone, Chibi, Sagittarius, Kawa, STklos, Scheme48, Loko, T prevent mutation, MIT, Gambit, Chicken, Guile, IronScheme, Bigloo, Loko, Gauche, Chez, Mosh, Larceny, Vicare, Picrin, Schemik, TinyScheme permit it. Furthermore, it is impossible to create one at run time or detect one.
That means that they do not serve the purposes of ipairs, that of guaranteeing (modulo frame-breaking implementation extensions) that they cannot be mutated by buggy code. Ipairs are, I claim, easier to reason about and easier to use in many situations, particularly extreme ones, than either ordinary pairs or literal pairs.
If all systems signaled an error on an attempt to mutate a literal pair, then indeed an `icons` analogue that returned a literal pair would suffice. But they don't and it's my belief that they won't. So if you want the advantages of immutability, you have to pay the cost of incompatible behavior.
I will, however, request another PFN for 116 that strikes out the claim that ordinary-pair operations should not support ipairs, and addis a recommendation for them to do so (nothing stronger is portable). This is not a matter of subtyping but of ad hoc polymorphism, as in SRFI 135 procedures that accept textuals.
Just drop "ipair?" from SRFI 116 and the route to
adoption is easy.
That is as much as to say "Drop SRFI 116 altogether", since it will no longer serve any purpose to write icar rather than car.
My point wasn't so much about the practicability or the probability of
mutation of data structures declared as immutable in one way or the
other; I wanted to stress the fact that we have been confusing two
meanings of immutability all the time,
And here I thought it was you who had been confusing them and I who had been striving to distinguish them. I am now trying again with a tripartite classification as above.
From a risk-mitigation viewpoint, you won't choose an implementation
that is silent on "(car 0)" either. We can expect that most quality
implementations will detect the error once they have found time to
adopt immutable strings, vectors and pairs.
We cannot expect them to do the latter: see above.
The good thing with this
approach is that all existing code will still work.
I don't understand this claim. Mutable pairs are not going away (except in Racket), so of course existing code will still work.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgAny sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)