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.
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
1. Personal attacks ("You're so dramatic!"), or
2. Flat denial that the problems exist?
Why are you even bothering with a review if you're unwilling to listen
to the advice that you're nominally asking for? Why do you respond to
criticism with personal abuse?
> 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.
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).
--
Bradd W. Szonye
http://www.szonye.com/bradd