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 <xxxxxx@sigwinch.xyz> 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 <xxxxxx@sigwinch.xyz>

"Types provide the means to put the meaning on machines,
to program computation as an act of explanation." --Conor McBride