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