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

[John A. De Goes]

I agree that type classes should not be used for this purpose. That's  
part of the reason I support "linguistic overloading" -- to stop the  
type class abuse.

Type classes should be used, as you say, when there are algorithms  
that work for arbitrary members -- i.e. the type class encodes  
structure and associated properties.

Regards,

John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101

On Feb 19, 2009, at 7:33 AM, Luke Palmer wrote:

> 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/b236ddad/attachment.htm