[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fundamental design flaws
> 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.
> 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
Bradd W. Szonye