On Thu, Oct 30, 2003 at 08:45:49AM -0800, Tom Lord wrote:
> to emulate cursors has at least three huge drawbacks, two of which
> pertain to efficiency, all three of which pertain to semantics:
>
> 1) The space consumption of the cursor is in general bound by the size
>    of the (entire) continuation of the call to the enumerator.
>    A call/cc cursor is going to gc-protect way, way, more than it
>    needs to.   (Sure, fairly aggressive optimization can do better
>    in some special cases but I think systems which do that will always
>    be exceptions rather than the rule.  Optimization of this sort will
>    only be possible when the compiler can do global flow analysis that
>    includes the implementation of the collection type.)
>
>    The interaction of this with other possible extensions like weak
>    references or first-class environments are scary to contemplate.

This is nothing compared to the kind of leaks that are possible with
cursors alone.  Thats one of the major arguments for enumeration after
all.

Btw, you're mistaken about call/cc and dynamic environments, I believe.
Try this code in a Scheme system:

(define x #f)
(begin (call/cc (lambda (k) (set! x k))) (display "hi"))
(current-output-port (open-output-file "/tmp/foo"))
(x)

>     > >           (error "there is no such thing as a set"))
>
>     > What a useful implementation _that_ would be!
>
> That's my point -- the specs are too weak.

Hardly.  A function like the one taylor wrote is explicitly illegal
based on the definition of union, assuming a real set is being passed.

>
> I'm saying: either don't try to operate on the Scheme types at all, or
> design 44 in such a way that the collections procedures work on (at
> least):
>
> 	ordinary lists as sequences (with any equivalence predicate)
> 	ordinary lists as sets (with any equivalence predicate)
> 	ordinary lists as ordered sequences
>           (with any equivalence /ordering predicate)
> 	ordinary associative lists as dictionaries (with any equivalence predicate)
>
> (and probably other things I'm forgetting.)

The problem here is that the generic inter-collection operators
(add-all, etc) are too useful.  Changing the SRFI to support
non-collection datastructures at the expense of this flexibility is just
not an option.  There is also a lot of new formalism in this SRFI that
you often need a more complicated datastructure to encapsulate, and
which needs to be passed around with the collection.

I think your mistake is confusing datastructures, which are low level
(lists, pairs, vectors) with collections.  A collection is a combination
of datastructure, semantics, and interface.

> So, minimally, TinyCLOS ought to have been included.   (It's tiny,
> right? :-)

I think this is a pretty good idea still.  We'd need to get permission
of course.