H98 module Array exports non-H98 instance Functor ((->) a)
Here's a subtle problem for which we have global class instances to thank.
Take a look at how many modules in base and the other core libraries re-export the class instances defined in Control.Monad.Instances. A lot do. Indeed the Data.Array and thus the H98 Array module does. That's very bad.
It makes it easy to accidentally write non-portable non-H98 code. This bit us in Cabal. We try to keep Cabal working with ghc, nhc98, hugs etc. Malcolm discovered that we were relying on the instance Functor ((->) a) but were not importing it for nhc98 at least. Nothing in Cabal imports Control.Monad.Instances so I was wondering how we were coming to end up with it. Turns out we're getting it at least via Data.Array.
Tracking down the source of instances is quite tricky. I wonder if there is anything we can do to make it easier? I was using ghc --show-iface on all the imports to try and find it. In this case it was easier because all I had to look for was Control.Monad.Instances as an orphan module.
We should audit which modules are importing Control.Monad.Instances and see if they're essential or just convenience. The point of Control.Monad.Instances being in a separate module was that it'd not be in scope by default. That's defeated if other standard modules use it. For example does Control.Applicative really need it? In fact Control.Applicative is probably the root offender here, it's the one that causes Data.Array to re-export the unwanted instances.
Do we need a Control.Applicative.Instances perhaps for the Applicative ((->) a) instance?
Trac metadata
Trac field | Value |
---|---|
Version | 6.8.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/haskell98 |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | Unknown |
Architecture | Unknown |