Edward Kmett wrote:
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.
In this case the package with the types and the package with the instances will have the same maintainer.
It is of course worse if they are exposed then you can wind up with incoherent dictionaries floating around for the same type.
Incoherent instances can only happen if someone else makes their own orphan instances. If they do that, they'll get a compiler warning, which should be sufficient.
That said, the only knowledge it is fossilizing is the existence of a single language feature, DeriveDataTypeable or Rank2Types.
The thing is, we have this excellent build system that abstracts language features from compilers, but we then go along and hack it up because people want both Data instances and Haskell 98 compatibility in the same package. It seems like the Right Thing in this case is to put the extra functionality in a separate package.
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.
Yes, I'm leaning towards hand-writing the instances so that Hugs might use them. -- Ashley