Claus Reinke wrote:
We have a test in GHC's test suite called instance-leak, which tests that none of the Haskell 98 libraries exports the Functor instance for (->). I broke this test recently by accident. How did I break it? By using Data.Map internally in System.Process. The Functor instance for (->) is exported from Control.Monad.Instances, makes its way into Data.Map, then into System.Process and thereby into System, which is a Haskell 98 module.
In your opinion, who or what is at fault for this test failure? You, of course:-p But seriously: I can't see easily how the instance even gets into Data.Map, but since Data.Map doesn't seem to be using either Functor or fmap (other than defining an instance itself), it has no business importing (and thus re-exporting) the instance. If it is actually using any of the other instances (is it?), then perhaps Control.Monad.Instances needs to be split up.
It seems that the ultimate offender is Control.Applicative, which imports Control.Monad.Instances() for no other reason than to infect its importers. That then propagates all over the place.
Good! I completely disagree. Control.Monad.Instances is at fault for exposing an orphan instance in the first place. Every other answer to the question leads to problems, I claim. Why is it wrong to say that Control.Applicative, or Data.Map, or my use of Data.Map in System.Process, are at fault? Because all of these modules just happen to be importing something that exports an orphan instance, and they can't be held responsible for re-exposing the orphan instance because they have no control over that. You will argue that they have control over what they import, and can thereby control whether they export the instance. This is certainly true, but it ignores the need for module abstraction: the need to be able to change the implementation of a module without changing its API. We must have the property that the imports of a module do not affect its API - and the only way to have this property is to avoid orphan instances in library APIs. (hmm, I finally feel like I've explained this clearly. I hope it comes across that way.) There are basically only two sensible choices for the Functor instance for (->): (a) don't define one at all (b) define one in Control.Monad, and give up on Haskell 98 compliance The current situation, namely (c) define it as an orphan, and give up on module abstraction is not a sensible choice. Incedentally, Iavor Diatchki pointed out to me today a nice way to provide "optional" instances for things in libraries. In your library if you have an abstract type T and want to suggest, but not mandate, a Functor instance, then you could export a function fmapT :: (a->b) -> T a -> T b so that a client can easily say instance Functor T where fmap = fmapT if they want. (but not in a library! A library would have to wrap T in a newtype to avoid an orphan instance.)
I assume the rationale is "convenience" again? Saving one import in importers at the price of limiting the modules that can afford to import Control.Applicative in the first place?
Since libraries@ is the maintainer for Control.Applicative, may I suggest to add Control.Applicative.Alt, differing from the original only in omitting the import of Control.Monad.Instances? Then all importers of Control.Applicative should be checked for whether import of Control.Applicative.Alt is sufficient, and be switched to that if possible.
That justs moves the problem around, and doesn't fix it. Cheers, Simon