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