[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fundamental design flaws

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.

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 

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"))

>     > >           (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.

Attachment: pgpafEzcYibkt.pgp
Description: PGP signature