[Haskell-cafe] Re: Overloading functions based on arguments?

Luke Palmer lrpalmer at gmail.com
Thu Feb 19 09:33:13 EST 2009


On Thu, Feb 19, 2009 at 7:09 AM, John A. De Goes <john at n-brain.net> wrote:

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090219/34ee9775/attachment.htm


More information about the Haskell-Cafe mailing list