[Haskell-cafe] ok, someone check me on this (type unification from the (>>=)/fmap thread)

[Miguel Mitrofanov]

On 10 May 2009, at 09:24, Brandon S. Allbery KF8NH wrote:

> I can't tell where I'm making the mistake here.

Frankly, I can't do it either, because I don't understand what you're  
talking about.

It seems that you have some idea of how the typechecker works, which  
is very different from that of mine.

I've explained my view on this subject in my response to Michael, and  
it doesn't involve the ((->) r) monad at all.

> In the thread where (>>=) and fmap were being confused, the error  
> cited a type (Maybe a) which was supposed to be in typeclass Num.   
> As far as I can tell, if the typechecker gets to the point where Num  
> and Maybe are both present and (m) is Maybe, it has to (1) be  
> focused on the (m b) part of (a -> m b), and therefore (2) must have  
> already unified (a) and (b).  But that means (m b) must unify with  
> (Num a => a), which is unified with (b), resulting in the attempt to  
> unify (Num a => a) with (Maybe a); since we get the error about  
> (Maybe a) not being a Num, it must not have gotten there.  But that  
> means it can't have related Num to (m a) with (m) bound to Maybe,  
> which is why I assumed it had unified (m) with ((->) r) instead.
>
> Can the typechecker really get the Num to the other end of (a -> m  
> b) without also getting the (a) there?  Or is it checking for the  
> Num constraint before it has fully evaluated the type of (m b)?  I  
> thought typeclass constraints happened later than basic type  
> unification.
>
> -- 
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
> system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
> electrical and computer engineering, carnegie mellon university     
> KF8NH
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe