Type class inference trouble

[Lars Lundgren]

On Sat, 17 Feb 2001, Ken Shan wrote:

> On 2001-02-16T09:52:41+0100, Lars Lundgren wrote:
> > This is ad hoc overloading, and IMHO bad style, at least in haskell. As I
> > understand it, haskell type classes were never intended to support this.
> 
> Well, whether this is ad hoc overloading depends on whether you find
> ad hoc this particular theory of how sentence fragments in natural
> language combine with each other... 

That particular theory is certainly unknown to the type class mechanism
and, I guess, hard to encode in it.

> I don't particularly want to
> overload like I can in C++; I just want to overload like people (are
> theorized by some linguists to) overload in English.
> 

That is very fine, I just wanted to warn you that type classes might not
be the best tool for the job. It's hard to appreciate type classes if you
think it is something it isn't. A screwdriver is a very useful tool, but
if you try to use it as a hammer you will get dissapointed.

Overloading in natural languages is very free, and very hard to formalize.
Overloading in haskell is intentionally much more restricted. The
overloading in C++ might be a better fit.


> In any case, I can certainly dump everything (Int, Int->Int->Int, and
> whatnot) into a single sum type, and perform my own type checking, but
> I'd rather not duplicate the work that Haskell has done for me.  A few
> minutes ago I came up with the idea of turning polymorphic types into
> non-polymorphic types using sum types, thus allowing polymorphic
> values, but I'll have to make things more concrete before I can say
> more about this idea.
> 

You lost me. I do not understand the connection between this and
overloading. I.e overloading is about syntax.

/Lars L