[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fundamental design flaws

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.

On Thu, Oct 30, 2003 at 01:54:59PM -0800, Bradd W. Szonye wrote:
> > Bradd W. Szonye wrote:
> >> No, it's a flaw in the design. You distinguish lists from alists
> >> according to content. You'll have isomorphism problems whenever the
> >> content of a list happens to match the structure of an alist. The only
> >> way to avoid that is to eliminate support for primitive alists -- which
> >> means eliminating support for one of the most common Scheme collections.
> scgmille@xxxxxxxxxxxxxxxxxx wrote:
> > No we don't.  Taylor can attest to that.  That was a bug in the
> > implementation at the time, it wasn't a problem previous to that
> > version, and isn't a problem now.
> 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.  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.

> -- 
> Bradd W. Szonye
> http://www.szonye.com/bradd


Attachment: pgpTxU1Q6iTkc.pgp
Description: PGP signature