> I agree that this is confusing. Here is a cut-down 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!
Indeed not. I salaam in your general direction. > 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 Pity. Do you see a way for the error message to avoid suggesting the 'possible fix', and indeed instead suggesting 'possible fix: remove the type signature from f'? > > Simon > > | -----Original Message----- From: > | [EMAIL PROTECTED] [mailto:glasgow-haskell-users- > | [EMAIL PROTECTED] On Behalf Of Norman Ramsey Sent: 06 December 2006 > | 01:41 To: Simon Peyton-Jones Cc: GHC users Subject: Re: [Haskell] GHC > | Error question > | > | > [redirecting to ghc users] > | > > | > It looks like a splendid error to me. > | > | I'm not sure if you meant the error or the message was splendid :-) > | I yelled for help because my usual strategy failed. That strategy is > | > | 1. Remove the type annotation. > | 2. Get ghci to tell me what the 'right type' is. > | 3. Put the 'right type' in the type annotation. > | > | I find it a bit depressing that the most general type inferred by ghci > | does not work as a type signature. > | > | > I can't say more without seeing the code. can you give a small repo > | > case? > | > | Yes, here's a case that fits in one screen of emacs :-) > | > | > | {-# OPTIONS -fglasgow-exts #-} > | module Ccomp where > | > | type Name = String > | > | data Inface = N | W > | data Outface = S | E > | > | data Sink box = Boxin Inface box | Result > | data Source box = Boxout Outface box | Arg Inface > | > | data Command = Send0 > | > | class (Monad b) => Builder b box where > | box :: Command -> b box > | wire :: Source box -> Sink box -> b () > | > | type Env box = Name -> Sink box > | > | empty = \x -> error (x ++ " not connected or multiply connected in > | circuit") > | > | -- either of these explicit signatures causes the compiler to fail -- > | although the inferred signature is the second. --compile1 :: (Builder b > | box) => Name -> Name -> ANF -> b Name compile1 :: (Builder t box) => t1 > | -> Name -> ANF -> t t1 -- generated by ghci compile1 f x body = do env <- > | compile body empty > | wire (Arg W) (env x) > | return f > | > | data ANF = ANF () > | > | compile :: (Builder b box) => ANF -> Env box -> b (Env box) > | compile (ANF m) out = undefined > | > | > | This program is rejected by GHC with the following message: > | > | > | > | Ccomp.hs:54:23: > | > | Could not deduce (Builder b box1) from the context (Builder b > | > | box) > | > | arising from use of `wire' at Ccomp.hs:54:23-42 > | > | Possible fix: > | > | add (Builder b box1) to the type signature(s) for `compile1' > | > | In the expression: wire (Arg W) (env x) > | > | In a 'do' expression: wire (Arg W) (env x) > | > | In the expression: > | > | do env <- compile body empty > | > | wire (Arg W) (env x) > | > | return f > | > | > | > | Note that compile1 has an explicit type signature much along the > | > | lines suggested by GHC. If I *remove* this type signature, the > | > | function compiles successfully, and ghci reporets this type for > | > | compile1: > | > | > | > | compile1 :: (Builder t box) => t1 -> Name -> Ir.ANF -> t t1 > | > | > | > | I believe this signature is isomorphic to the explicit signature I > | > | had attempted to use. > | _______________________________________________ > | Glasgow-haskell-users mailing list > | [email protected] > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
