RE: Mismatched contexts

Haskell98 reqires that mutually recursive functions all have the same context.  
It's a piece of conservative language design: we thought we could lift the 
restriction but weren't quite sure of all the consequences.   Perhaps I should 
just drop the check with
 -fglasgow-exts.  

Is your example a cut down version of a real program where the restriction bit 
you?   And if so, was the program easily fixed to pacify the restriction?

Simon


| -----Original Message-----
| From: glasgow-haskell-bugs-bounces@xxxxxxxxxxx [mailto:glasgow-haskell-bugs-
| bounces@xxxxxxxxxxx] On Behalf Of Armin Größlinger
| Sent: 01 December 2003 16:46
| To: glasgow-haskell-bugs@xxxxxxxxxxx
| Subject: Mismatched contexts
| 
| Hello,
| 
| I observed the following behavior on GHC-6.0.1 and CVS HEAD.
| With -fglasgow-exts the following program
| 
| 
| data Functions =
|     Functions { f1, f2 :: Integral a => a -> a }
| 
| functions :: Functions
| functions =
|     Functions { f1 = (\x -> x),
|               f2 = f2b
|             }
| 
| f2a, f2b :: Integral a => a -> a
| 
| f2a = f1 functions
| f2b x = x
| 
| 
| is accepted by GHC, but if I change
|   f2 = f2b
| to
|   f2 = f2a
| in the definition of `functions', GHC says
| 
|     Mismatched contexts
|     When matching the contexts of the signatures for
|       functions :: Functions
|       f2a :: forall a. (Integral a) => a -> a
|     The signature contexts in a mutually recursive group
|       should all be identical
|     When generalising the type(s) for functions, f2a
| 
| (This can be "fixed", as I found out, by adding a dummy type
| variable to the Functions data type:
| 
|   data Functions dummy = ...
|   functions :: Integral dummy => Functions dummy
| )
| 
| I don't understand why the contexts must be identical in mutually recursive
| definitions. `f2a' should have the right type, since it is explicitly
| declared to have the same type as `f2b'. Is GHC wrong here, or am I
| misunderstanding something?
| 
| Regards,
| Armin
| _______________________________________________
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@xxxxxxxxxxx
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs