On Wed, Apr 11, 2012 at 12:45 PM, Florian Weimer <[email protected]> wrote: > * Jeremy Shaw: > >> The place where you really run into trouble is when you depend on two >> libraries which both contain an orphan instance for the same type. >> There is nothing you can do to work around that, AFAIK. And, that is >> part of what makes orphan instances risky. On the other hand, that has >> never happened to me in 10 years of Haskell programming. So, that is >> probably why there isn't much clamoring to do something about it. > > It's also not different from a scenario where two libraries use two > types for exactly the same concept (IPv4 addresses) or closely related > ones (strings as bytes, UTF-8, UTF-32 etc., or different kind of > number types in SML). > > In the end, lack of global coordination will always require some ugly > plumbing, no matter how fancy the language is.
Ugly plumbing is one thing. But the problem here is that you get a compile time error that can *only* be fixed by modifying one of those libraries so that it no longer defines the conflicting orphan instance. There is no way to hide the conflicting instances when importing a module. (That is not an oversight, but a fundamental design issue). In an open-source world, modifying the library is viable option. But if both libraries are closed sourced -- you are pretty much screwed. You have to wait for your vendors to decide to help you.. It's rather unfortunate. I love type-classes -- they are one of the reasons I love Haskell. But.. there are some tough issues with them that still have not been solved. And the solutions might be quite disruptive. - jeremy _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
