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



On Thu, Oct 30, 2003 at 01:18:31PM -0800, 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.
> 
> scgmille@xxxxxxxxxxxxxxxxxx wrote:
> > You're so dramatic Bradd.
> 
> 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. 

> > You can very well have concrete types in SRFI-44, its just that trying
> > to wedge the non-collection types from Scheme in that causes problems.
> 
> 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.  
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.

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

	Scott

Attachment: pgp6ZRu4J5tv5.pgp
Description: PGP signature