On Sat, Jun 5, 2021 at 8:05 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
Wolfgang, what do you think? We should get it right with SRFI 224 first > (before it is finalized) and then we can correct SRFI 113 and 146 (am I > missing another relevant SRFI) ex post facto. > I haven't been following this thread closely, but it seems to me that the topic has drifted from functional vs. linear-update *procedures* to persistent vs. transient *objects*. Invoking (foo-swizzle bar) guarantees that bar will not be visibly mutated, whereas invoking (foo-swizzle! bar) makes no such guarantee. If foo objects are not in fact mutable, these are probably the same procedure. If foos are in fact mutable, then foo-swizzle probably makes a copy and foo-swizzle! does not. Only in the case where foos can be either immutable or mutable is it necessary to have two types and keep track of what you've got, and provide foo-freeze and foo-thaw to convert between them And there is an alternative to this, namely the Builder pattern, in which foos and foo-builders have entirely separate APIs: foos are immutable, whereas foo-builders are not, but only support mutation operations and cannot be used as foos. We have generally avoided the Builder pattern in favor of the Constructor pattern, but there are cases (histograms are my favorite one) where mutability is highly desirable, and the Builder pattern might be a win.
