time library dependencies
ashley at semantic.org
Wed Jun 3 17:51:29 EDT 2009
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
More information about the Libraries