Am Mo., 7. Juni 2021 um 20:55 Uhr schrieb Wolfgang Corcoran-Mathe < [email protected]>:
> Thanks for taking the time to write up a clear summary. I found > this very helpful. > > While I think this approach can solve the problem, it's a radical > departure from the designs of many existing Scheme libraries. > 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. As Shiro has noticed, the current status is definitely not one that should persist. > 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. Moreover, SRFI 1 acts on non-opaque values while the sets and mappings of SRFI 113 and SRFI 146 are opaque. It only makes sense to allow the possibility to store a transient/persistent flag with the latter to improve reporting of logical errors. > On 2021-06-07 08:51 +0200, Marc Nieper-Wißkirchen wrote: > > Note that the constructors return transient mappings. The reason is that > > these transient mappings can be cheaply converted to persistent mappings > > (by the logical operation transient->persistent, which can be implemented > > as a no-op), while the conversion in the other direction involves a copy. > > While this is clearly the Right Thing, it is clumsy to have to > If it is the Right Thing, then it is the right thing. Or it is not. > compose every constructor with transient->persistent, as you'll > have to do if you aren't intending to use any of the -! forms: > > (cons 0 (transient->persistent (list 1 2))) > As I said above, the discussion does not apply to SRFI 1. It would be artificial to add it to SRFI 1. > This kind of mandatory verbosity often triggers distaste and even > hostility from some programmers. It is especially onerous in the > context of implementations which don't provide any linear-update > variant procedures, where the distinction between transient and > persistent data is empty. > > 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. This means adding even more names, of course, but it > has the merit of allowing the programmer to work with just the > persistent-object forms without extensive conversions; indeed, they > might be able to completely ignore the -! forms without issue. > 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 !.
