On Thu, Nov 26, 2009 at 2:27 PM, Joachim Breitner
PS@-cafe: I still have doubts that this approach will scale as hackage grows. We’d get a lot more dependencies than we have now, and still would face this problem every now and then. Or do you really want packages that provide data types (like time) depend on all the libraries that do some kind of conversion (binary, html, xhtml, json, yaml, etc.)?
It's something I wonder about myself. Here's a thought experiment: Lets say I want to provide an alternate or additional library of monad transformer data types. To make these types maximally useful, they should implement the typeclasses in the mtl package and in the monads-tf package. The only way to do this in a reasonable way is with multiple packages and orphan instances: mypackage mypackage-classes-tf mypackage-classes-fd where the 'classes' packages do nothing but provide class implementations. But then we're in a tight spot if someone doesn't notice that I have the mypackage-classes-tf package released, provides their own instances, and ships them in a library. Am I missing something? And how can we extend the language to make this better? Does anything short of class-instance explicit import/export make this better? Antoine