I am getting the impression that we have to rethink the whole mutability/immutability thing. For strings, we haven't yet found a solution that is accepted by most. For pairs, the R6RS approach didn't seem to go far, while SRFI 116 seems to have its own share of problems. If the reference to literal pairs (that they are immutable may also be important to compilers!) is removed, we can make ipairs a completely disjoint type to pairs, but apart from tagging the objects differently, any Scheme implementation could make both types isomorphic (and this will most often be the most efficient solution), so SRFI 116 wouldn't add anything. Maybe the root of the problem is that we are trying to encode or formalize a guarantee here that is of algorithmic nature. In some sense, it's a bit like trying to define a new type of procedures that do not call call/cc. (Such a type of procedure could come handy when one wants to simplify higher-order procedures.) SRFI 101, which also deals with functional lists, is different. It contains new algorithms so it really adds something to the language. Racket's approach to make all pair immutable is, if I am not mistaken, less motivated by what seems to be the motivation of SRFI 116, but motivated by the fact that "apply" and rest argument handling can be implemented much more efficiently when there is a guarantee that the rest argument is not mutated. Am Di., 12. Mai 2020 um 22:10 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > Thanks! Now I'm thinking that I ought to remove a good deal more, though. > > It's probably true that there is no way to *guarantee* the immutability of anything in Scheme, as it is always possible that a particular Scheme will extend the domain of some mutator to affect other objects than the one it was meant for. But as a practical matter, immutability is a useful property, and I think I will simply drop all discussion of literal pairs altogether in the PFN. > > The reason for literal pairs being immutable, I think, is to make sure that interpreters don't have to cope with self-modifying code. One of the earliest Fortran compiler had a bug such that if you passed a constant to a procedure by reference (which is how Fortran does all calls) and the procedure modified its argument, the value of the constant in the caller also changed! > > On Tue, May 12, 2020 at 3:57 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote: >> >> In response to this thread, John sent me a pull request that adds a post-finalization note to this SRFI and makes some minor edits, too. Here is the diff: >> >> https://github.com/scheme-requests-for-implementation/srfi-116/commit/bd038e02
