Type classes in Backpack signatures are dodgy

At the moment, we allow exactly the same type class declarations in hsig files as we do in hs-boot files, and matching requires the type class definitions to match up exactly. But this is quite questionable.

First, this means that I can't write this in a signature:

class K a where
  f :: a -> Bool

but then implement K with a type class that provides a default. The matching code will say these are not compatible. That's not so useful.

Second, it means that I can WRITE a default implementation in a signature file. That seems like a step too far: there are many things I might like to write in a specification of a type class, but what the default methods are seems like a step too far.

So it seems we need to fix two things:

1. Relax matching so that you can add defaults post-facto in the implementation of the type class
2. Make hsig more restrictive w.r.t. what class definitions it will accept.

Trac metadata

Trac field	Value
Version	8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (Type checker)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture