Email list hosting service & mailing list manager

Linear update procedures Marc Nieper-Wißkirchen (22 May 2017 08:38 UTC)
Re: Linear update procedures Alex Shinn (22 May 2017 09:00 UTC)
Re: Linear update procedures John Cowan (22 May 2017 14:30 UTC)
Re: Linear update procedures Per Bothner (22 May 2017 17:59 UTC)
Re: Linear update procedures Marc Nieper-Wißkirchen (24 May 2017 05:39 UTC)
Re: Linear update procedures Alex Shinn (24 May 2017 13:42 UTC)
Re: Linear update procedures Marc Nieper-Wißkirchen (01 Jul 2017 18:27 UTC)
Re: Linear update procedures Alex Shinn (23 May 2017 01:42 UTC)

Linear update procedures Marc Nieper-Wißkirchen 22 May 2017 08:38 UTC

Having linear update procedures is, in my opinion, important for
practical use cases of SRFI 113 (sets) and SRFI 146 (mappings) and, to
some extent, SRFI 1 (lists). They allow to use destructive algorithms in
a functional setting, and thus greatly increase the expressiveness.
Without them, SRFI 113 and 146 would lose a lot of their beauty (in my
opinion).

I agree that having some compiler support would be great as would having
some type-safety (using annotations, for example); however, SRFIs
allowing to implement these sorts of things are still to be written.

The naming of the linear update procedures may be debatable, but SRFI 1
(and SRFI 113) already set the standard.

To maintain orthogonality with existing SRFIs already voted into
R7RS-large (SRFI 1 and 113), I am not going to rename the linear update
procedures, nor am I going to remove them. I think it should be left to
further SRFIs (amending the Red Edition of R7RS-large) to (1)
bulk-rename the linear update procedures of SRFI 1, 113, 146 and maybe
other SRFIs and (2) provide the means for compiler support.

Marc