On Wed, Jun 3, 2009 at 3:33 AM, Ashley Yakeley
<ashley@semantic.org> wrote:
wren ng thornton wrote:
Yeah, orphan instances are bad.
I already use private orphan modules within the package, though the package does not externally expose any orphan instances.
They are fine if they aren't exposed, right up until the package with their definition decides to provide the instance themselves, at which point your orphan violates encapsulation. It is of course worse if they are exposed then you can wind up with incoherent dictionaries floating around for the same type.
I'm with Edward Kmett here, for the time package, having compiler-dependent instances seems like the least evil. (For other packages, it depends on the classes and on how easy it would be to avoid the problem.)
The downside is that the package has to know, and fossilize, information about compilers. Though I will go this way if orphan instances are shown to be sufficiently problematic.
That said, the only knowledge it is fossilizing is the existence of a single language feature, DeriveDataTypeable or Rank2Types. On further reflection, using Rank2Types is probably a better way to go than DeriveDataTypeable, if somewhat more effort, if only because Hugs can support the former, but not the latter.
-Edward Kmett
--
Ashley