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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe