time library dependencies

[Edward Kmett]

On Wed, Jun 3, 2009 at 3:33 AM, Ashley Yakeley <ashley at semantic.org> wrote:

> wren ng thornton wrote:
>
>> Yeah, orphan instances are bad.
>>
>
> Why?
>
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20090603/4a3bdda4/attachment-0001.html