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