time library dependencies

[Ashley Yakeley]

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