Functional and linear-updating interfaces Shiro Kawai 31 May 2021 11:05 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 12:45 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 31 May 2021 15:53 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 16:16 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 16:34 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 31 May 2021 16:55 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 17:36 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 31 May 2021 18:06 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 20:56 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 31 May 2021 23:14 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 01 Jun 2021 06:14 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 02 Jun 2021 06:01 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 02 Jun 2021 06:31 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 02 Jun 2021 10:48 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 02 Jun 2021 11:44 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 02 Jun 2021 17:18 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 05 Jun 2021 12:05 UTC
Re: Functional and linear-updating interfaces John Cowan 06 Jun 2021 16:55 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 06 Jun 2021 17:36 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 06 Jun 2021 18:05 UTC
Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 07 Jun 2021 01:20 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 07 Jun 2021 04:54 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 07 Jun 2021 06:51 UTC
Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 07 Jun 2021 18:55 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 07 Jun 2021 20:34 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 07 Jun 2021 20:46 UTC
Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 07 Jun 2021 22:19 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 07 Jun 2021 20:39 UTC
Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 07 Jun 2021 22:17 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 08 Jun 2021 06:18 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 07 Jun 2021 20:53 UTC
Re: Functional and linear-updating interfaces Shiro Kawai 07 Jun 2021 23:33 UTC
Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 31 May 2021 23:15 UTC
Re: Functional and linear-updating interfaces Arthur A. Gleckler 31 May 2021 14:38 UTC
Re: Functional and linear-updating interfaces Marc Nieper-Wißkirchen 31 May 2021 14:42 UTC

Re: Functional and linear-updating interfaces Wolfgang Corcoran-Mathe 07 Jun 2021 18:55 UTC

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