[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fundamental design flaws

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

scgmille@xxxxxxxxxxxxxxxxxx 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

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

You really need to learn the difference between comments about your
proposal and comments about you personally.
Bradd W. Szonye