On Sat, Jun 26, 2021 at 12:24 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
> @John: Thanks for chiming in. > > The case of SRFI 1 is very different from the cases of all other > container-type SRFIs affected by the question of linear-update procedures. > While SRFI 1 may have initially motivated the idea of linear update > procedures in the other container-type SRFIs, the ideal behind SRFI 1's > linear-update procedures is special (mostly because SRFI 1 operates on a > concrete data type whose implementation is fully exposed to the user). > > Thus, in this thread, I have been talking solely about the container-type > SRFIs that provide opaque data types. It is just not sensible trying to > treat these and SRFI 1 on the same footing. The approach I have been > discussing here gets rid of the *linear* update procedures in the > container-type SRFIs so that the mutating part of the APIs will look like, > say, the mutating procedures of SRFI 125. The question of SRFI 1's linear > update procedures is orthogonal to this. > > So what is your overall opinion about this new proposal, John? I've tried > to make it efficient(ly implementable), that it resolves the various > objections against linear update procedures (by Per, Shiro, Wolfgang, and > others), that it is simple to implement, and that its API can be used > without surprises. > Pinging John in case he can help resolve this thread.
