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 Bradd W. Szonye 30 Oct 2003 21:35 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