Am Mo., 7. Juni 2021 um 22:35 Uhr schrieb Shiro Kawai <[email protected] >:
> 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. > We are not in a rush to finalize SRFI 224, are we? > 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." > I think this should be formulated in terms defined by the Scheme language. The notions of "live references" or "shared internal structure" are implementation details not defined by the RnRS. > 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.) > This agrees with my observation that all constructors should return transient objects by default if we use this terminology. > - 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. > Again, "deep copy" should be expressed in terms of the defined semantics of Scheme.
