On 2 February 2016 9:33:46 AM AEDT, "Wojtek Narczyński" <wojtek@power.com.pl> wrote:
On 01.02.2016 21:34, Ben wrote:
 But there *could* be other instances the compiler just can't see at 
 the moment (because it's in another module that's not imported). 
 Someone else could then import this module and that other module and 
 observe inconsistent instances.


Okay, I get it. In another module there might be instances Eq and 
Typeable for ANY, and then the instances would indeed overlap. It makes 
sense.

 To avoid that problem, the type class system *never* commits to 
 "negative" information; if an instance choice is only valid because 
 there *isn't* a possible instance in scope then that instance choice 
 is not valid after
all.


I will have to produce many instances by hand.

Couldn't the compiler just postpone the its overlap checking until 
linking? Or might I forbid creation of Eq and Typeable instances of ANY?

It potentially could, but it didn't (the design isn't without tradeoffs).

What you can do is look into overlapping instances; you can make the compiler allow those two instances to overlap and pick the most specific one that applies at each use site. It still wouldn't be actually using the constraints to choose the instance, but in code that statically knows its talking about Any it can use that instance, and if it's an unknown type variable you presumably *won't* be able to prove Typeable or Eq if it could possibly be Any, so the code still wouldn't compile.

I have very rarely actually used this, because it can be a little "dangerous" (you can get those inconsistent instances the ignore-the-instance-constraints rule is designed to avoid), but with a little discipline it can work fine. Read up on the GHC documentation on the OverlappingInstances extension.