Using an inferred type as a type signature fails

[simonpj]

See the thread starting here  http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011714.html. Here's a short example:

class C a b where
   op :: a -> a

-- f :: C a b => a -> a
f x = op x

It doesn't get much simpler than that! With the type sig, GHC can't see that the (C a b) provided can satisfy the (C a b1) which arises from the call to op. However, without the constraint, GHC simply abstracts over the constrains arising in the RHS, namely (C a b1), and hence infers the type

        f :: C a b1 => a -> a

It is extremely undesirable that the inferred type does not work as a type signature, but I don't see how to fix it easily. It doesn't affect many programs, I think; hence low priority

[simonpj]

See also Oleg's message  http://www.haskell.org/pipermail/haskell-cafe/2006-December/020538.html

[guest]

I'm interested in the resolution of this. Added to CC.

[morabbin]

Defect still present in GHC 7.6.1, but I'm seeing some oddness in the number of errors presented with multiples:

{-# LANGUAGE MultiParamTypeClasses #-}

class C a b where
   op :: a -> a

f1 :: C a b => a -> a
f1 x = op x

f2 :: C a b => a -> a
f2 x = op x

If we give both type signatures, both fail. If we give neither, both fail (albeit with a different error). Leave out only one type signature, and only that function fails to type. Or, more likely, the other failure is not reported.

I have files to attach if deemed worthwhile (no patch, just files that show the four behaviors).

[simonpj]

GHC always checks each type signature for ambiguity; if that faile, it just stops, since ambiguous signatures can lead to futher errors. If there are no sigatures, it goes ahead and tries to typecheck both defns, finding an ambiguous inferred type for each.

It's not perfect, but I think it's good enough.

Simon