Am Mo., 31. Mai 2021 um 18:16 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:

Using mutability is a second-optimal solution, and we can have 'ensure-mutable' procedure that copies the input if it's immutable and passes through if it's mutable, as well as the ordinary copy procedure.   Then, an intermediate library that potentially takes functional or linear type arguments can avoid unnecessary copying.  If the caller of such a library wants to pass a mutable shared object, he can just explicitly copy it.

But then, if every intermediate library puts the ensure-mutable procedure, we can just embed it into the original linear-updating API, which became the strategy I outlined in the original email.

In this case, you make implicit what should IMO be explicit. Implicit casting and ad-hoc polymorphism is often not the best idea.

PS By the philosophy of R7RS, it would "be an error" to apply a linear updater to a result returned by a functional updater. But as implementations of R7RS are allowed to extend the domain of standard procedures, an implementation could choose not to show an error but instead do the conversion implicitly.

So even with my stricter proposal, an implementation strategy like yours would be allowed in the world of R7RS. An R6RS implementation, however, would have to signal an error.