> Bradd W. Szonye wrote:
>> How do the generic procedures know whether '((a . 1) (b . 2)) is a
>> list or an alist? If it's based on content, you have isomorphism
>> issues to resolve. If you're now using something like a record type
>> for alists, then you're not really handling primitive alists.

xxxxxx@freenetproject.org wrote:
> They never receive ((a . 1) (b . 2)).  They receive an alist-dict,
> which has structure beyond the stored values which it can dispatch on
> (Taylor can comment more).  We don't handle primitive alists.

You make a big deal about how important it is to provide generic
procedures for collections, but you don't support a very common
collection type? Code that uses alists must choose between a complete
port or no support? Actually, I suppose that a genuine alist would look
like a "list" to SRFI-44.

Could you please explain how this is consistent with your goals? While
it may be a good idea not to support "primitive" Scheme collections, it
doesn't seem compatible with your goals.

> It was never the intention of the "Scheme Collections" section to make
> the Scheme types work with collections.  It was the intention to write
> collections that used the underlying Scheme types to store values, to
> show how they behave if they are collections.

So are primitive lists and vectors supposed to be real collections,
implemented by all SRFI-44 providers? If not, then why are they in the
SRFI? If so, then how do you deal with lists and vectors that aren't
*just* lists and vectors? Does SRFI-44 really treat a Scheme alist as if
it were just a simple list?

It'd be better to use distinct, non-primitive types for *all* of them,
rather than fooling around with primitive ADTs inconsistently. If you
do, however, be careful to rename "list" and "vector," like you renamed
"alist."
--
Bradd W. Szonye
http://www.szonye.com/bradd