Type class problem

[Simon Peyton-Jones]

| > b) at the moment dictionaries have the property that you can always
| > 	evaluate them using call-by-value; if they could be recursively
| > 	defined (as you suggest) that would no longer be the case
| >
| > Mind you, GHC doesn't currently take advantage of (b), so maybe it
| > should be ignored.  Adding the current goal as an axiom would not be
| > difficult, but I don't have time to do it today!  Is anyone else
| > interested in such a feature?
|=20
| I would like to try making this change, but I couldn't puzzle out
enough
| of the type class system the last time I looked. I would appreciate
| advice, references, or even just a list of the relevant modules.

If you want to try fiddling with GHC, try the -fdicts-strict flag, and
look for where it is used in the source (opt_DictsStrict).  The
predicate Type.isStrictPred is also relevant.

| Allowing implications in contexts even allows us to derive instances
for
| some irregular types:
|=20
| data Twice f x =3D T (f (f x))
| data Growing f =3D G (f (Growing (Twice f)))
| data Id x =3D Id x
|=20
| Suppose we want to define instances that will imply Show (Growing Id).
| Growing Id is an irregular type so allowing irregular derivations
isn't
| enough, but the following instances are acceptable
|=20
| instance (forall a.Show a =3D> Show f a,Show x) =3D> Show (Twice f x)
where
|   show (T ffx) =3D show "T "++show ffx

Indeed so. That's exactly what the "Deriving type classes" paper points
out, and Valery's Haskell Workshp 2003 paper "Simulating quantified
class constraints" is also highly relevant.

Simon