Re: Fundamental design flaws

[Tom Lord <lord@xxxxxxx>]

    > From: scgmille@xxxxxxxxxxxxxxxxxx

    >> 1) [call/cc cursors capture protect their continuation]

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

I have no idea what you're talking about.


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

What do you think I'm mistaken about?  I was thinking about typical
implementations of WITH-{INPUT,OUTPUT}-FILE which handle escape
continuations as you'd expect (which, admittedly, is not required by
R5RS).  In general, any feature of a program that uses dynamic scope
is going to interact awkwardly, at best, with call/cc-cursors.


    > >     > >           (error "there is no such thing as a set"))

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

But since 44 gives no way to create a real set, a conforming
implementation can use implementations that just call error.


    > > 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): [e.g., uses of lists as sequences, sets, ordered
    > > sequences, and (as association lists) dictionaries.]

    > The problem here is that the generic inter-collection operators
    > (add-all, etc) are too useful.  

There are plenty of ways to do operations like that that don't rely on 
a collection type -- and some of those ways are better.

If I want to ADD-ALL from some list, I want different things depending
on whether I'm using the list as a sequence or a dictionary.   Do you
think it's impossible to provide interfaces that let me make that 
distinction?



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

That's a red herring.

Lists and associatve lists are an example of non-disjoint types both
of which have a clear interpretation both as a sequence and a
dictionary but I don't think they are the only one.

It is an inessential property of a sequence that it also be
not-a-dictionary.   Introducing collection procedure which require
sequences to be disjoint from dictionaries treats that inessential
distinction as an essential one:  it makes the interfaces in 44 less
suitable for future extension.

-t