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.
>
> xxxxxx@freenetproject.org 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