On 2 February 2016 9:33:46 AM AEDT, "Wojtek Narczyński"
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?
-- Wojtek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
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.