``Orphan instances'' can be good.

[kahl at cas.mcmaster.ca]

Simon Peyton Jones wrote:

 > | Data/Time/Calendar/Gregorian.hs:73:9:
 > |     Warning: orphan instance: instance Show Day
 > | [...]
 > 
 > Now that orphan warnings are "proper warnings" as Duncan requested, and
 > hence do the right thing with -Werror, someone should either remove this
 > orphan (best), by moving the instance to the module that defines Day,

I just would like to point out that there is nothing inherently bad about
what GHC calls ``orphan instances''.

From a code structuring point of view,
I frequently ``consider orphan'' instances
useful for separation of concerns.

Just consider a simple, prelude-based example:
Read instances tend to pull in dependencies (e.g. Parsec)
that a new datatype as such does not need,
and the new datatyps's Read instance is also not needed
everywhere where the type is needed itself.
So I frequently create MyDatatypeRead modules
with explicit, empty export lists,
to export only the (``orphan'') instance.


Orphan warnings are only an implementation-specific hint
about an implementation-specific problem ---
checking the GHC user manual again,
I find that ``GHC tries to be clever'',
and ``orphan instances'' are documented as only a situation
that prolongs compile time.

 > or add -fno-warn-orphans to this module.

I have no problem with this
(of course I would consider using a OPTIONS_GHC pragma the preferable way);
I just would like to emphasise that there is no implementation-independent
reason to avoid ``orphan instances''.


(On the implementation side, a completely different solution would be
 to add (automatically) re-exported instances (and rewrite rules)
 to the export lists stored inside .hi files ---
 then ``orphan instances'' would be no worse than other instances.)


Wolfram