Ah, I see.  Thanks very much.  For some reason I figured the second type 
would be resolved to Int, but now I see that is totally wrong.

Best,  

Sean

On Sat, Sep 12, 2009 at 8:34 PM, Brandon S. Allbery KF8NH <allbery@ece.cmu.edu> wrote:
On Sep 12, 2009, at 20:17 , Sean McLaughlin wrote:
However, if you replace the function f with

f :: (MonadState s m, Has Int s) => m Int
f = do x <- project
          y <- project
          return x

then it fails with the error

    Could not deduce (Has á s)
      from the context (MonadState s m, Has Int s)
      arising from a use of `project'
                   at /Users/sean/uploads/Weird.hs:16:12-18
    Possible fix:
      add (Has á s) to the context of the type signature for `f'
    In a stmt of a 'do' expression: y <- project
    In the expression:
        do x <- project
           y <- project
           return x
    In the definition of `f':
        f = do x <- project
               y <- project
               return x

I think what this is really telling you is that there's no way for ghc to tell what type y has.  x is fine because it's in the result (hence fixed by the type (m Int)), but y is just "there" and all ghc knows is that it has (Has á s) and (MonadState s m, Has Int s) but no way to get from one to the other (more specifically:  it has no clue what á might be).

Note that project is explicitly polymorphic, so the fact that you used it to get an (Int) does not in any sense guarantee that the subsequent use *also* produces an Int.  If you want this, you'll have to constrain the call somehow.

-- 
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