The linear-update SRFIs and what to do about them John Cowan (14 Jun 2021 19:15 UTC)
Re: The linear-update SRFIs and what to do about them Arthur A. Gleckler (14 Jun 2021 21:05 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (14 Jun 2021 22:34 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (15 Jun 2021 09:40 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (15 Jun 2021 21:25 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (16 Jun 2021 08:12 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (19 Jun 2021 12:34 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (19 Jun 2021 12:57 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (19 Jun 2021 23:25 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (20 Jun 2021 06:55 UTC)
Re: The linear-update SRFIs and what to do about them Arthur A. Gleckler (21 Jun 2021 16:58 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (21 Jun 2021 17:35 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (23 Jun 2021 17:55 UTC)
Re: The linear-update SRFIs and what to do about them Arthur A. Gleckler (23 Jun 2021 18:20 UTC)
Re: The linear-update SRFIs and what to do about them Marc Nieper-Wißkirchen (23 Jun 2021 19:06 UTC)
Re: The linear-update SRFIs and what to do about them Arthur A. Gleckler (20 Jun 2021 00:28 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (20 Jun 2021 02:09 UTC)
Re: The linear-update SRFIs and what to do about them Wolfgang Corcoran-Mathe (20 Jun 2021 02:14 UTC)
Re: The linear-update SRFIs and what to do about them Arthur A. Gleckler (20 Jun 2021 02:33 UTC)
Re: The linear-update SRFIs and what to do about them John Cowan (22 Jun 2021 21:44 UTC)

Re: The linear-update SRFIs and what to do about them Wolfgang Corcoran-Mathe 20 Jun 2021 02:14 UTC

> >> 3) Convert all SRFI 209 linear-update procedures to mutational ones.
> >> This will require a new implementation, which Wolfgang has agreed to
> >> provide.  Draft PFN:
> >>
> >> Post-finalization note 1: The author recommends that the entire section
> >> "Linear update" be ignored, and that the procedures whose names end in ! be
> >> implemented by mutation of their enum set  arguments.  However, for
> >> backward compatibility they should return the mutated enum set, unlike
> >> other mutational procedures which return an unspecified value.
> >>
> >> Arthur: do you think this is appropriate as a PFN?
> >>
> >
> > As far as I can see, the same argument applies here as for SRFI 113, so
> > yes.
> >
> > Are you ready for me to add the PFNs now?
> >
>
> Let's wait until we have the new implementation for 209.  113 can go as
> soon as we see if there are any comments from the 113 mailing list, I think.

It's ready.  I just opened a pull request (on GitHub) for it.

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

"In a great man's work, at its fastest, no line is thrown away, and
it is not by the rapidity, but the economy of the execution that
you know him to be great." --John Ruskin