Strange error in show for datatype

[Jan-Willem Maessen]

"Simon Peyton-Jones" <simonpj@microsoft.com> tries his hand at
inventing free theorems for qualified types, then concludes:
> In which case we could report ambiguity a bit less often.  How
> useful this would be I don't know.

A lot.  Any time one is testing the empty case of a bulk type.  If
you're coding data structures work (and most first and second year CS
classes will) that happens all the time.  It comes up in situations as
simple as making sure your functions return [] when you expect them
to.

So a clever solution to this problem would make hugs, ghci, etc. far
more usable.  It would also allow the monomorphism restriction to be
relaxed at absolutely no cost in certain cases.

Earlier, Simon says:
> Indeed, if none of the classes have a method that returns
> an a-value without also consuming one (urk-- strictly, I think, sigh)
> then the same holds.

Strictness alas matters.  Here's the witness:

class Num a => ZeroList a where
  consZero :: a -> [a]
  consZero _ = 0:xs

instance ZeroList Int

instance ZeroList Double

Now:

(consZero (error "no type")) :: (ConsNum a) => [a]
show (consZero (error "no type")) :: (ConsNum a) => String

Do we get "[0]" or "[0.0]"?

OK, we have a problem worth addressing, and a non-obvious (or absent)
solution.  I'd love to hear what our resident type theorists have to say.

-Jan-Willem Maessen
Eager Haskell Project