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.
> There's this note: > > When % is encountered in the definitions below, the actual name of > the collection is implied. > > so, no, they are not supposed to be `*'. Sorry, I missed that. And I think it should be "collection's supertypes" instead of "collections supertypes" in the paragraph explaining the use of "*". > > Although it is customary not to define the return value of > > destructive functions, the *-remove! functions might return #f or #t > > to indicate whether the collection was actually modified, since > > removing a value that is not present is not defined as an error. > > I would say that if you *have* an iterator (and the collection is > mutable), then you have a value that can be removed. So, IMHO, > sticking with the undefined returned value is correct, and concurs > with most other SRFIs that include destructive ops (except, perhaps > SRFI-1 where these are called linear updates). > > (Besides tradition, I've nothing against returning useful values from > destructive ops, though.) I totally agree with you, but the procedures in question do not require an iterator. I am thinking of (list-remove! (list 1 2 3) 44), for instance. And come to think of it, why define destructive procedures rather than non-destructive ones in the first place? Especially after going to such lengths to define purely functional iterators. Regards Michael Burschik