Am Di., 8. Juni 2021 um 00:17 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> On 2021-06-07 22:39 +0200, Marc Nieper-Wißkirchen wrote: > > Am Mo., 7. Juni 2021 um 20:55 Uhr schrieb Wolfgang Corcoran-Mathe < > > [email protected]>: > > > Adopting it now in new libraries without feedback and testing from > > > many more Schemers seems premature to me; as you say, we'd want to > > > proceed carefully to ensure that we make the best choice for the > > > signature of each library form. > > > > SRFI 113 and SRFI 146 in their current form also haven't been tested > > before. But I understand that the change may be too big for a PFN. In > this > > case, the best way would be to write replacement SRFIs and to withdraw > SRFI > > 113 and 146 then. In any case, we should wait with finalizing SRFI 224 if > > this is possible until the issue with the earlier SRFIs is resolved. > > I'd also like to get this right, but, if the solution involves > revising at least two finalized SRFIs, this will take a while. > I'd prefer to make most of the changes Shiro suggested to SRFI 224 > and finalize it, rather than asking Arthur to wait an indeterminate > amount of time. > Can you word the changes in a way so that they only refer to the well-defined terms of Scheme's semantics described in the RnRS? In any case, I am wondering whether anyone would benefit from finalizing SRFI 224. When SRFI 113 and SRFI 146 are updated, SRFI 224 would have to updated as well (so that it remains in line with the other two SRFIs). So the current SRFI 224 spec seems to be preliminary to me. (I should add that my objection here partly overlaps with my more general point of criticism with respect to the R7RS-large process: When I write a book, I never finalize the first chapter before the last has been written. As far as I am concerned, I would consider all of R7RS-large, including the colored editions, still in draft status until we are done with all components.) > What other SRFIs are affected, beyond 113 and 146? > That's a good question! > > > I'm thinking that the best way to start with this overhaul may be > > > to write updated versions of affected SRFIs. (To make sense of > > > the idea, e.g., I started to write a wrapper for SRFI 1.) Showing > > > people how this works with well-known libraries might give them a > > > reason to accept it in unfamiliar libraries. > > > > > > > I'm not sure whether SRFI 1 is related enough to SRFI 113 and SRFI 146 > and > > the issue discussed here. While SRFI 1 has linear update procedures, it > > doesn't have the awful requirement that the functional update procedures > > (e.g. cons) return newly allocated lists. > > I agree, although think SRFI 1 still has related problems. Several > procedures in SRFI 1 (e.g. `concatenate') may entail structure-sharing > (and do, in the widely-used sample implementation), which can cause > bugs when they are combined with the linear-update procedures. > That's true, but any correction of this would be truly out of the scope of SRFI 1. As I wrote in an earlier post, SRFI 1 is concerned with a concrete representation of a data type. This makes it very different from SRFI 113 and SRFI 146. > One negative outcome from the status quo is the "newly allocated" > protocol; I believe that another is the problem of "unsafe" > implementations which use structure sharing and expect you to be > aware of it. SRFI 1's sample implementation is an example of the > latter. > As SRFI 1 is on the level of (mutable) pairs, one cannot do much (and shouldn't do much) for SRFI 1 in this respect. I am worrying add SRFI 1 to the mix obscures the specific issues of SRFI 113 and SRFI 146. > > As a convenience, it makes sense to me to provide two versions of > > > each commonly-used constructor, one for persistent and one for > > > transient objects. In terms of naming, the -! suffix makes just > > > as much sense here, e.g.: > > > > > > list! : <object>* → <transient list> > > > list : <object>* → <persistent list> > > > > > > cons! : <object> <transient list> → <transient list> > > > cons : <object> <persistent list> → <persistent list> > > > > > > and so on. > > > > The !-suffix is generally added to procedures that mutate existing > > allocated locations. It would be confusing to give constructors, which > > don't do this, names ending in !. > > I'd call it an abuse of notation, but I do think there's a nice > symmetry to it: PROCs operate on persistent values, PROC!s operate > on transient. > I think it is an example of a very bad abuse of notation. There's even no symmetry involved because any such symmetry would conflate co- and contravariance. We shouldn't ignore the established naming conventions. For example, there's make-vector and not make-vector! in the RnRS. Compare this with vector-copy and vector-copy! and you see the difference. > In any case, naming is hard. You may not consider it an issue, but > I still anticipate some throwing of objects if we tell people they > need to explicitly persistent-ify every set/mapping/etc. they > construct. Having another constructor which is simply a composition > of the form transient->persistent ∘ CONSTRUCTOR seems like a nice > convenience. > I understand this point. An ad-hoc naming convention that does not clash with the !-suffix could be helpful here. We have mapping: <comparator> <object>* -> <transient mapping>, so the obvious version post-composed with "transient->persistent" would be persistent-mapping: <comparator> <object>* -> <transient mapping>. In case this is too long, we can think of a single or two-letter prefix like the "m" in Racket's mutable pairs or the "i" in SRFI 116's immutable lists. Speaking of the "i"-prefix: Are there any chances to change SRFI 224's i-prefix into something different? Both SRFI 116 and SRFI 134 (both being part of R7RS-large) use the "i" prefix to denote immutability. (At one point, SRFI 140 also uses this convention and other SRFIs probably as well.) The current clash of meanings is unfortunate and potentially confusing especially because the notion of an "immutable integer mapping" actually makes sense. Please fix this before it is too late. Marc
