On Feb 14, 2009, at 2:29 PM, Luke Palmer wrote:
To me, typeclasses are at their best when you have a real abstraction to encode.
I agree.
If you are having trouble using a typeclass and need C++-style ad- hoc overloading, it's likely you are trying to encode a "fake" abstraction -- one that has only linguistic, rather than mathematical meaning.
I don't think what you're calling a "linguistic" abstraction is "fake". Words and operators have connotations in the minds of those reading them. There's a reason I choose the word, 'flatten' rather than 'sdj834' to name a function -- because the word 'flatten' suggests what I am trying to accomplish with the function. Let's try a little test: 1. If the parameter is a tree, what do you think "flatten" would do? 2. If the parameter is a list, what do you think "flatten" would do? 3. If the parameter is a Style (possible a composite Style consisting of other styles), what do you think "flatten" would do? 4. If the parameter is a Bezier curve, what do you think "flatten" would do? My guess is that we would come to the same conclusions for (1) - (4). The name "flatten" is a perfectly good name for all of these operations, because the domains are distinct, and because using that name suggests the correct meaning to you. (Note use of the word "suggests" -- like an analogy or parable, you're likely not going to know exactly what the function does just by reading its name, but you'll be in the ballpark and have an intuition about it, which is extremely valuable.) In the current world, "flatten" will be appended with (usually non- informative) suffixes, or alternate, less-descriptive names chosen. Informative coding is about drawing upon our common pool of experience to mold the form and function of programs to suggest our intentions to others. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101