Mismatched contexts

[Armin Größlinger]

Hello,

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

Yes, the example is from a real program. The situations is as in my example. 
We have different functions for solving a certain problem (like f2a and f2b 
in the example) and want to store the functions which are currently selected 
(by the user) in a record ("Functions" in my example, in the real program the 
type is more like "IORef Functions"). Some of the more complex functions use 
a function solving a more basic problem in their implementation, i.e., they 
take the selected implementation to solve the basic problems from the record. 
That's how we get a mutual recursion between the record and a function (like 
with f2a).

The current "fix" in our program is to use a dummy type variable, like 

  data Functions dummy = ...
  functions :: Integral dummy => Functions dummy
  functions = ...

and then the type variables "a" (in the function's context declaration) und 
"dummy" can unify. Our program works nicely with this hack, so the 
restriction is not a real problem for us.

Regards,
Armin

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