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