> 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