Anton van Straaten wrote:
> Some adapters which take a Scheme type and return a collection could
> do this, presumably within the bounds of the current 44 spec, although
> I haven't tried to prove that to myself.  Would that approach satisfy
> you, or do you think that the collection procedures should be able to
> operate directly on "unwrapped" Scheme types?

There are some advantages to folding the primitive data structures into
the collection hierarchy. For example, you can specify that ADD accepts
a collection argument and have it "just work" for (ADD cv '(1 2 3)).

Unfortunately, it's currently specified in a way that creates ambiguity.
Is an alist a dictionary or a sequence? What about a list that happens
to look like an alist? In some OO systems (e.g., prototype-based OO),
that kind of value-based overloading is exactly what you want. It's very
handy for stuff like geometry subtyping, where you *want* an ellipse to
answer yes to "isa circle?" whenever the two axes happen to be equal.
But it's very surprising if you're not expecting that kind of
isomorphism. In particular, it's easy to violate interface preconditions
or postconditions unless you carefully construct your type relationships
and delegation patterns with this in mind.

Currently, SRFI-44 doesn't address this issue. It specifies isomorphic
types, but it doesn't deal with the consequences of that decision.

It would be very cool if SRFI-44 could somehow permit isomorphism and
make it work, without surprises. But the current design doesn't take it
into account, so you end up with surprises like the list of pairs that
acts like a dictionary. Same goes for lists of lists, because those too
are lists of pairs.

If that's too difficult, then it's better to eliminate the isomorphism,
which effectively means no dispatching on primitive types. And without
them, SRFI-44 has no concrete collections at all. With no concrete
collections and no defined method for dispatch, all that's left is
vapor.
--
Bradd W. Szonye
http://www.szonye.com/bradd