This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
> > The SRFI document refers to mutability in several places, yet the only > mutating operations defined are linear updates. Linear update, as it is > currently defined is "optional", ie. linear update operations are free > to return fresh data structures. Thus linear update is little more than > an optimization technique based on hints from the user, and the SRFI > does not cater for mutable collections. > > Many Schemes have mutable collections (e.g. hash tables are usually > defined as mutable collections) and there is a substantial code base > that relies on this mutability. Such code could not be easily modified > to take advantage of this SRFI, which seems unfortunate. > > Mutation is evil in most cases, but it can be useful. That's why Scheme > has set!, set-car! and set-cdr!. So can we please have mutable collections. It seems that adding language that allowed compatible SRFI's to declare whether they are linear-updating or purely side-effecting may solve this problem. In the latter case, the update procedures would still return the input collection, allowing code written straight to SRFI-44 to still function, but code written specifically to the child SRFI would be allowed to ignore the return value. For example, the following snippets would be legal, and both would return the same value: (define h (make-hashtable eq?)) (let* ((h1 (dictionary-put! h 1 'a)) (h2 (dictionary-put! h 2 'b))) (collection-fold-keys-increasing h2 (lambda (k ls) (values #t (cons k ls))) '())) (begin (dictionary-put! h 1 'a) (dictionary-put! h 2 'b) (collection-fold-keys-increasing h (lambda (k ls) (values #t (cons k ls))) '())) Scott
Description: PGP signature