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 22:17 UTC

On 2021-06-07 22:39 +0200, Marc Nieper-Wißkirchen wrote:
> Am Mo., 7. Juni 2021 um 20:55 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
> > 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.
>
> SRFI 113 and SRFI 146 in their current form also haven't been tested
> before. But I understand that the change may be too big for a PFN. In this
> case, the best way would be to write replacement SRFIs and to withdraw SRFI
> 113 and 146 then. In any case, we should wait with finalizing SRFI 224 if
> this is possible until the issue with the earlier SRFIs is resolved.

I'd also like to get this right, but, if the solution involves
revising at least two finalized SRFIs, this will take a while.
I'd prefer to make most of the changes Shiro suggested to SRFI 224
and finalize it, rather than asking Arthur to wait an indeterminate
amount of time.

What other SRFIs are affected, beyond 113 and 146?

> > 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.
> >
>
> I'm not sure whether SRFI 1 is related enough to SRFI 113 and SRFI 146 and
> the issue discussed here. While SRFI 1 has linear update procedures, it
> doesn't have the awful requirement that the functional update procedures
> (e.g. cons) return newly allocated lists.

I agree, although think SRFI 1 still has related problems.  Several
procedures in SRFI 1 (e.g. `concatenate') may entail structure-sharing
(and do, in the widely-used sample implementation), which can cause
bugs when they are combined with the linear-update procedures.

One negative outcome from the status quo is the "newly allocated"
protocol; I believe that another is the problem of "unsafe"
implementations which use structure sharing and expect you to be
aware of it.  SRFI 1's sample implementation is an example of the
latter.

> > 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.
>
> The !-suffix is generally added to procedures that mutate existing
> allocated locations. It would be confusing to give constructors, which
> don't do this, names ending in !.

I'd call it an abuse of notation, but I do think there's a nice
symmetry to it: PROCs operate on persistent values, PROC!s operate
on transient.

In any case, naming is hard.  You may not consider it an issue, but
I still anticipate some throwing of objects if we tell people they
need to explicitly persistent-ify every set/mapping/etc. they
construct.  Having another constructor which is simply a composition
of the form transient->persistent ∘ CONSTRUCTOR seems like a nice
convenience.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"I have discovered a truly marvelous implementation of this
function which this 80-column limit is too narrow to contain."
--fishythefish