On Thu, Oct 30, 2003 at 01:02:10PM -0800, Tom Lord wrote:
>
>
>
>     > From: xxxxxx@freenetproject.org
>
>     >> 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.

Go read the paper about Enumeration vs Cursors that oleg cited please.

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

Only if the conversion operator happens outside the scope of a function
which is managing such things.  I don't think this alone is persuasive
though.

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

Just because SRFI-44 doesn't specify a set, and doesn't specify
extensibility doesn't mean that a set cannot be created.  And if it is
created, the above behavior is patently illegal.

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

Yes, but they all imply program knowledge at the call point.  Agnostic
collection usage doesn't.  This is how modular, datastructure
independent code is written in the real world.

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

I disagree.  It creates quite a semantic mess if collections are allowed
to take on different forms in different contexts.  Its trivial to have a
*representation* that can take on both forms though.

(define x (make-list))
(generic-operator x) ; treat it as a sequence
(generic-operator (list->dictionary x))

Only in very rare cases can you hope to have even a low level
datastructure that takes on multiple forms.  Lists do this, but in most
cases datastructures that can behave in more than one way do require
some fixup first. So its actually quite preferred to require a cast
operator of some sort.

Even better, if you use a cast, its trivially implemented if we're also
using adapters to allow Scheme datatypes to behave as collections.  Its
much harder otherwise.

	Scott