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