Hi,
[yet another haskell list to subscribe to.. and I'll start with
a rant, sorry - I've quickly scanned the archive, but this
doesn't seem to have come up before, has it?]
Problem:
As noted elsewhere, we've been running into problems with Haskell's
"fine" handling of instances while trying to combine some largish
Haskell projects. As long as the language isn't changed, this
problem needs to be accounted for in library designs.
Concrete examples: Control.Monad.Error, Control.Monad.Reader
These modules define lots of instances for (Either a) and ((->) a).
Why? Obviously, they want to use them, but that's no excuse.
Both Either and (->) are very popular type constructors, and
currently, every project that wants to use these instances defines
them somewhere. Result: as soon as you put two of these projects
together, you get a clash!
In current Haskell, defining instances of public classes for public
types/constructors has side-effects running through the whole of any
program using such a library. Quite apart from the facts that the
module names typically gives no indication of these side-effects,
and that the modules could have been implemented without them (using
standard types/constructors was just more convenient), there's no
way to get two such modules to work together in a larger project
without changing them!
Solution:
I'd suggest a two-way approach:
1) There are some commonly expected, but unfortunately not predefined
instances of public classes for public types, such as Monad and
Functor for (Either a) or for ((->)a)
These should go into separate modules, to be imported into every
project depending on them. Result: no conflict, and each of the
projects works, both on its own and in combination with other
such projects.
It is important that the instances can be imported selectively,
without fear of getting other, unwanted, stuff in the process.
ShowFunctions.hs would have been an example of this (where did
that go, btw?).
In Control.Monad.Error, the case is actually worse: not only does
it have the unexpected side-effect of stealing some "standard"
instances, it defines some of them in non-standard ways:
instance (Error e) => Monad (Either e) where
return = Right
Left l >>= _ = Left l
Right r >>= k = k r
fail msg = Left (strMsg msg)
Here, Error and strMsg are local to the Error module, and the design
prescribes that fail *must* return Left of something, rendering
it impossible to use this definition to get any other behaviour.
2) If a module needs instances of public classes for public
types/constructors, but in non-standard ways, it should
copy&rename either the class or the type/constructor. This way,
the standard ADT services of the module mechanism prevent conflicts
(the instances are still flowing around, but unseen..).
Given that some syntactic sugar and other functionality depends on
classes with fixed names, such as Monad, most modules will create
their own variant of the type, not of the class.
For instance, Control.Monad.Error would probably need to define its
own variant of Either. That could be a simple newtype wrapper.
I haven't checked the libraries systematically. This is just one
example we ran into in practice (meaning that these libraries are
actually used, making them vulnerable to complaints;-).
Hope this makes sense?
Claus
PS. perhaps this suggestion got lost in the other thread, but
could Haddock please show the source of any instances in the
generated documentation?
