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