I agree to Wolfgang that we should proceed cautiously rather than hastily throwing in this new idea. I started putting transient/persistent semantics in Gauche libraries to see how it goes.
In srfi-224, there's no longer "returns newly allocated object" phrase, so I think it leaves enough room for the future persistent/transient clarification srfi. I think a few tweaks may help the implementers to avoid pitfalls, unless you think it's redundant. - In Linear update section, we can emphasize that potentially mutated object should't have internal structures shared with other objects, because functional interface may return a new imapping that shares some internal structure with the input. E.g. "there are no other live references to, nor shared internal structure in, the potentially-modified imapping." We can also say that, in general, newly constructed objects, a result of imapping-copy, and a result of other linear-updating procedures are the only ones that can be safely passed to the linear-updating procedure. - I think all constructors can return "new mappings", unless the implementation adops purely functional semantics. (If it's pure functional, for example, (imapping) can return a singleton empty imapping. If linear-updating interface does modify the arguments, you need a guarantee that each construction returns a fresh object.) - In imapping-copy, after the "immutable imapping" clause, we may say if the implementation chooses to let the linear-updating interface modify its arguments, imapping-copy returns deep-copy (no internal structure is shared). So that the result can be safely passed to the linear-updating interface. On Mon, Jun 7, 2021 at 8:55 AM Wolfgang Corcoran-Mathe <[email protected]> wrote: > 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. > > 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. > > 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 > 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))) > > 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. > > -- > Wolfgang Corcoran-Mathe <[email protected]> > > "Types provide the means to put the meaning on machines, > to program computation as an act of explanation." --Conor McBride >
