On Thu, Feb 19, 2009 at 7:09 AM, John A. De Goes
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".
Please ignore the word "fake". I don't want to get into any subjective arguments based on the connotation of that word. What I mean to say is, the theory of typeclasses is good at encoding mathematical abstractions, and bad at encoding linguistic ones. Take that as you will, but I conjecture that trying to cram linguistic overloading into a typeclass is generally going to be painful. A good rule of thumb is: are there any algorithms which work for an arbitrary member of this class? I certainly cannot see any for your flatten example. I'm not saying that linguistic overloading is a bad thing. You make good arguments for it, and I find it cleans up code sometimes. Typeclasses just aren't the right tool for it, and Haskell has no good tool for it. In fact, I think it a very interesting research question to come up with a mechanism that supports linguistic overloading, and interacts with typeclasses and inference cleanly. The obvious solution (just look in your namespace for one that matches) has serious drawbacks, and nothing else is jumping to mind.