Am Sa., 16. Mai 2020 um 03:03 Uhr schrieb John Cowan <xxxxxx@ccil.org>: >> In any case, if the ipairs are made disjoint to pairs, this would >> change the semantics of this SRFI quite a lot, so it would definitely >> need a new SRFI. > > > Well, the SRFI editor has accepted this change as a post-finalization note, so that's definitive. But whether to accept the PFN as part of R7RS-large will be on the next ballot. The SRFI editor and you are, of course, free to add whatever you want to this SRFI, but, frankly speaking, putting this in a post-finalization note is very bad in my opinion. It's not a simple change of what counts as an implementation, but a major change. It cannot be cured, say, by simply replacing one embedded library (like it was with the PFNs concerning the replacement of SRFI 114 with SRFI 128). The PFN does not cure a defect of the old version that would have made it unusable. The apparent self-contradiction with respect to the Liskov Substitution Principle is gone, but that doesn't mean that the underlying inconsistency I mentioned in the initial post is resolved. I would ask you, Arthur and John, to reconsider this and, instead start a process for a replacing SRFI if we really want the new semantics John proposes. While a PFN may not be normative, some implementations will now provide the old semantics under the SRFI 116 name, other implementations will provide the new semantics. That worse than just one semantics. >> However, I would advise against forcing ipairs and pair literals to be >> disjoint. Otherwise, implementations will be forced to deal with three >> types of pairs, > > > Only a handful of Schemes (Cyclone, Chibi, Sagittarius, Kawa, STklos, Scheme48) that I know for sure) actually treat literal pairs differently. Note that several of these are interpreters. In Kawa's Java classes, ImmutablePair is a subclass of Pair, which violates the LSP; attempting to set the car or cdr throws a dynamic exception, which is fine in a dynamic language. Whether literal pairs are indeed immutable or not doesn't change the fact that they have to be treated differently semantically. Because it is "an error" to modify them. We use the same language for ipairs. >> all of which have to be implemented efficiently >> (important for pairs!). We should remember that the number of tag bits >> available are limited. > > > I would expect that ipairs would normally be records rather than special-case representations. With good tagging, pairs are represented by a pair of two cells. A record will very likely need at most three cells (one for the reference to the RTD, two for the payload). This means that ipairs will in many cases be less efficient than pairs. > Chibi has a bit in each non-immediate value for immutability, but persuading Scheme implementers to redesign their internal data representations is very difficult and may break existing FFI-using programs. Chicken has no bit to spare on 32-bit systems, which are still pretty important. Move the data structure into a part of the heap that is mprotected. >> Whatever the final shape of SRFI 116 and immutable pairs will be, it >> would be great if we find a solution that does not result in >> duplication of code (most interfaces in all R7RS-large libraries (have >> to) accept and yield mutable pairs) and will be adopted by the users >> (we are having this discussion with immutable strings as well). > > > The debate is about *how* we do immutable strings rather than whether we do them. We all speak about immutability but we have never nailed down what we mean by it. So saying that we need "immutable" strings is not yet well-defined. :) The naive definition "a string/pair is immutable if it cannot be mutated after creation" is obviously wrong. Schemes are free to add introspection procedures, extend the domains of standard functions, etc., so there may always be a way to modify any object round the back. (The Scheme model is an open-world, not a closed-world model.) Alternatively, we can define "an immutable object" by saying "it is an error to modify the object". This is akin to the const modifier in the C language. To make use of this version of immutability, we don't necessarily have to add new types to the Scheme language (which has the problem that every new fundamental type is badly integrated with the existing procedures). It's just about semantics. For example, when I have a functional data structure which shared structure where some procedures return objects, I may want to declare these objects "immutable" (meaning that it is an error to mutate them), but for the objects do not have to be of a separate Scheme type. And to repeat Will Clinger: What do we exactly mean by a Scheme type? What other possible definitions of "immutable object" have I missed? >> If we find a convincing solution where the immutable pairs already >> dictated by literals > > > Not dictated. It is completely conformant to extend RnRS by allowing the mutation of immutable objects. and even R6RS only says that mutating a literal *should* raise an &assertion object. The same goes for the ipairs. That's why the third version of pairs seems to be a bit too much. > >> >> form the base of ipairs, that would be the best >> as implementations, and users already know these > > > I doubt if most users are even aware of immutable objects unless they have fallen over them in a Scheme that raises an error. Many users are also unaware of call/cc, define-syntax, parameterize, values, ... :) So I must have spoken about the well-informed user who is looking for a coherent platform. :) >> >> What I can think of is a procedure `freeze` that takes a general >> Scheme object and returns an immutable Scheme object that is `equal?` >> to it. This can be efficiently implemented by copying the data >> structure to a memory area that can be mprotected to be read-only. > > > Makes sense. If you write a SRFI that provides `freeze!` (linear-update) and `frozen?`, I'll add it ot the Green or Olive Docket (non-portable). I am not sure about whether `frozen?` shall be part of the spec. With it, a trivial implementation (for Schemes that don't (need) to care) won't be possible. However, without it, the semantics of `freeze!' is hard to describe (it could be the identity). Whatever the final shape of such a SRFI: Don't you think that it could be used to support the use cases of the ipairs of SRFI 116 without the need of creating a disjoint type? Marc
