Fundamental design flaws Tom Lord (29 Oct 2003 17:46 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (29 Oct 2003 19:13 UTC)
Re: Fundamental design flaws Bradd W. Szonye (29 Oct 2003 20:06 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (29 Oct 2003 20:47 UTC)
Re: Fundamental design flaws Tom Lord (29 Oct 2003 23:24 UTC)
Re: Fundamental design flaws Taylor Campbell (30 Oct 2003 01:53 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 16:52 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 17:11 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 16:33 UTC)
RE: Fundamental design flaws Anton van Straaten (30 Oct 2003 16:52 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 17:19 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 18:13 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:18 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:26 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:35 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:49 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:55 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 22:05 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 22:28 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 22:52 UTC)
Re: Fundamental design flaws Alex Shinn (31 Oct 2003 03:04 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (31 Oct 2003 03:20 UTC)
Re: Fundamental design flaws Alex Shinn (31 Oct 2003 07:13 UTC)
RE: Fundamental design flaws Anton van Straaten (30 Oct 2003 23:07 UTC)
Re: Fundamental design flaws Bradd W. Szonye (31 Oct 2003 03:12 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:57 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 20:23 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:35 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 17:06 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 17:26 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 18:15 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 18:48 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 19:35 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 19:45 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:08 UTC)
Re: Fundamental design flaws bear (30 Oct 2003 20:40 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 20:48 UTC)
Re: Fundamental design flaws Tom Lord (30 Oct 2003 20:49 UTC)
Re: Fundamental design flaws scgmille@xxxxxx (30 Oct 2003 21:02 UTC)
Re: Fundamental design flaws Bradd W. Szonye (30 Oct 2003 21:26 UTC)

Re: Fundamental design flaws Tom Lord 30 Oct 2003 20:36 UTC

    > From: "Anton van Straaten" <xxxxxx@appsolutions.com>

    > Tom Lord wrote:
    > > I'm saying: either don't try to operate on the Scheme types at all, or
    > > design 44 in such a way that the collections procedures work on (at
    > > least):

    > > 	ordinary lists as sequences (with any equivalence predicate)
    > > 	ordinary lists as sets (with any equivalence predicate)
    > > 	ordinary lists as ordered sequences
    > >           (with any equivalence /ordering predicate)
    > > 	ordinary associative lists as dictionaries (with any
    > > equivalence predicate)

    > > (and probably other things I'm forgetting.)

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

I realize that "Scheme style" tends to favor abstraction to a greater
degree than traditional lisp but I don't think that traditional lisp
style should be quite so neglected.

I'd be satisfied with, for example, a sequences and dictionaries
pacakge that works on nothing but "wrapped types" (e.g., not directly
on lists or vectors).

I'd _prefer_ one that where both sequences and dictionaries could be
ordinary association lists.

The only obstacle I see to that is the idea in 44 that both sequences
and dictionaries are "collections" where operations on collections
need to discriminate between sequences and dictionaries.

-t