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