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)
|
xxxxxx@freenetproject.org wrote: > Bradd W. Szonye wrote: >> Bradd wrote: >>>> If that's too difficult, then it's better to eliminate the >>>> isomorphism, which effectively means no dispatching on primitive >>>> types. And without them, SRFI-44 has no concrete collections at all. >>>> With no concrete collections and no defined method for dispatch, all >>>> that's left is vapor. Bradd wrote: >> I'm not trying to be "dramatic." I'm trying to point out a fundamental >> design problem. SRFI-44 specifies isomorphic types but does not address >> the common problems that isomorphism can cause. Why do you consistently >> respond to major issues with either > I'm refering to statements you make like "Srfi-44 has no concrete > collections at all", which did not follow logically from your argument. Could you please at least *try* to read for comprehension? "And without them [the primitive ADTs -- list, vector, and string], SRFI-44 has no concrete collections at all." Your out-of-context quotation completely changes the meaning of what I wrote. >> You really don't get it, do you? Did you even understand a word of >> what I wrote? This response doesn't even tangentially address what I >> wrote. It's not "wedging the non-collection types from Scheme" that >> causes the problem. It's your *design* that causes the problem. You >> identify those types isomorphically, but you don't deal with the >> consequences. > No we don't. Those problems were bugs in the reference > implementation. 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. > The SRFI requires that any collection cannot exist as two types at > once. This will be made explicit when the Dispatch Mechanism section > is completed. That too is a design flaw. How many people need to tell you that before it sinks in? Notice how alists *already* exist as two collection types as once? >> If you would spend more time trying to *design a good product* and >> less time coming up with new ways to insult your reviewers, you might >> actually be able to resolve the issues (by eliminating the >> isomorphism or finding a way to deal with it gracefully). > I find this paragraph particularly ironic given the tone and content > of your arguments previously. Are you capable of telling the difference between criticism and insult? It doesn't seem that way, because you keep responding to my criticism as though I were trying to insult you personally. Meanwhile, you *constantly* fling insults aimed straight at the reviewers, not at their comments. You really need to learn the difference between comments about your proposal and comments about you personally. -- Bradd W. Szonye http://www.szonye.com/bradd