I'm also in general in favor of linear update procedures. Even if every implementation

always uses mutation, I think the functional API is cleaner and easier to remember.

The only cause for confusion seems to be with the use of ! for naming, and the fact

that many conventional languages perform similar operations as in-place mutations.

To consider some alternatives for the future:

foo?! : ? maybe ! update (also appropriately means "dubious" in chess notation)

foo✂ : scissors indicate we are cutting up (consuming the input), conveniently pointed in the right direction

foo8< : ascii representation of scissors

Alex

On Mon, May 22, 2017 at 5:38 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

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

To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=4eZyIyhrtw6TQR9jBxWCAsegdJ1FH8un