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