<sect2 id="gadt-style">
<title>Declaring data types with explicit constructor signatures</title>
-<para>GHC allows you to declare an algebraic data type by
+<para>When the <literal>GADTSyntax</literal> extension is enabled,
+GHC allows you to declare an algebraic data type by
giving the type signatures of constructors explicitly. For example:
<programlisting>
data Maybe a where
the <emphasis>instance declaration</emphasis> itself, controlled by the
presence or otherwise of the <option>-XOverlappingInstances</option>
and <option>-XIncoherentInstances</option> flags when that module is
-being defined. Neither flag is required in a module that imports and uses the
-instance declaration. Specifically, during the lookup process:
+being defined. Specifically, during the lookup process:
<itemizedlist>
<listitem><para>
-An instance declaration is ignored during the lookup process if (a) a more specific
-match is found, and (b) the instance declaration was compiled with
-<option>-XOverlappingInstances</option>. The flag setting for the
-more-specific instance does not matter.
+If the constraint being looked up matches two instance declarations IA and IB,
+and
+<itemizedlist>
+<listitem><para>IB is a substitution instance of IA (but not vice versa);
+that is, IB is strictly more specific than IA</para></listitem>
+<listitem><para>either IA or IB was compiled with <option>-XOverlappingInstances</option></para></listitem>
+</itemizedlist>
+then the less-specific instance IA is ignored.
</para></listitem>
<listitem><para>
Suppose an instance declaration does not match the constraint being looked up, but
-does unify with it, so that it might match when the constraint is further
+does <emphasis>unify</emphasis> with it, so that it might match when the constraint is further
instantiated. Usually GHC will regard this as a reason for not committing to
some other constraint. But if the instance declaration was compiled with
<option>-XIncoherentInstances</option>, GHC will skip the "does-it-unify?"
These rules make it possible for a library author to design a library that relies on
overlapping instances without the library client having to know.
</para>
-<para>
-If an instance declaration is compiled without
-<option>-XOverlappingInstances</option>,
-then that instance can never be overlapped. This could perhaps be
-inconvenient. Perhaps the rule should instead say that the
-<emphasis>overlapping</emphasis> instance declaration should be compiled in
-this way, rather than the <emphasis>overlapped</emphasis> one. Perhaps overlap
-at a usage site should be permitted regardless of how the instance declarations
-are compiled, if the <option>-XOverlappingInstances</option> flag is
-used at the usage site. (Mind you, the exact usage site can occasionally be
-hard to pin down.) We are interested to receive feedback on these points.
-</para>
<para>The <option>-XIncoherentInstances</option> flag implies the
<option>-XOverlappingInstances</option> flag, but not vice versa.
</para>