On Wed, Apr 30, 2003 at 04:53:01PM +0200, Michael Burschik wrote:
> > 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.

Yeah, its probably reasonable to return false if nothing was removed.
>
> 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.

The short answer is that while an iterator can easily be functional and
efficient (because it usually only needs a small amount of state, like a
pointer), a datastructure may not be.  Take as an example an actively
balanced tree.  A functional version of remove may have to do a lot of
work to modify the tree, but even more if its not allowed to affect the
original (possibly as bad as copying the entire tree).  At best this
creates a lot of extra GC pressure.

The other answer (same as in c.l.s) is that some collections may be
difficult to implement functionally, for example the database resultset,
because accessing it may cross out of Scheme into a very non-functional
land like a C-style database API.

	Scott