be a disaster in practice, so GHC tries to be clever. </para>
<para>In particular, if an instance declaration is in the same module as the definition
-of any type or class mentioned in the head of the instance declaration, then
+of any type or class mentioned in the <emphasis>head</emphasis> of the instance declaration
+(the part after the “<literal>=></literal>”; see <xref linkend="instance-rules"/>), then
GHC has to visit that interface file anyway. Example:</para>
<programlisting>
module A where
class E x y | y -> x where ...
</programlisting>
Then in some importing module M, the constraint <literal>(E a Int)</literal> should be "improved" by setting
-<literal>a = Int</literal>, <emphasis>even though there is no explicit mention
+<literal>a = T</literal>, <emphasis>even though there is no explicit mention
of <literal>T</literal> in M</emphasis>.</para>
These considerations lead to the following definition of an orphan module:
</para></listitem>
</itemizedlist>
</para>
- <para> Only the instance head (the part after the “<literal>=></literal>”)
+ <para> Only the instance head
counts. In the example above, it is not good enough for C's declaration
to be in module A; it must be the declaration of D or T.</para>
</listitem>
-<para>GHC will warn you if you are creating an orphan module, if you add `-fwarn-orphan-modules`.
+<para>If you use the flag <option>-fwarn-orphans</option>, GHC will warn you
+if you are creating an orphan module.
+Like any warning, you can switch the warning off with <option>-fno-warn-orphans</option>,
+and <option>-Werror</option>
+will make the compilation fail if the warning is issued.
+</para>
+<para>
You can identify an orphan module by looking in its interface
file, <filename>M.hi</filename>, using the
<link linkend="modes"><option>--show-iface</option> mode</link>. If there is a <literal>[orphan module]</literal> on the