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.
> 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. scgmille@xxxxxxxxxxxxxxxxxx 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