+ <sect4 id="assoc-type-instance">
+ <title>Associated type instance declarations</title>
+ <para>
+ When an associated family instance is declared within a type class
+ instance, we drop the <literal>instance</literal> keyword in the family
+ instance. So, the <literal>[e]</literal> instance
+ for <literal>Elem</literal> becomes:
+<programlisting>
+instance (Eq (Elem [e])) => Collects ([e]) where
+ type Elem [e] = e
+ ...
+</programlisting>
+ The most important point about associated family instances is that the
+ type indexes corresponding to class parameters must be identical to the
+ type given in the instance head; here this is <literal>[e]</literal>,
+ which coincides with the only class parameter.
+ </para>
+ <para>
+ Instances for an associated family can only appear as part of instances
+ declarations of the class in which the family was declared - just as
+ with the equations of the methods of a class. Also in correspondence to
+ how methods are handled, declarations of associated types can be omitted
+ in class instances. If an associated family instance is omitted, the
+ corresponding instance type is not inhabited; i.e., only diverging
+ expressions, such as <literal>undefined</literal>, can assume the type.
+ </para>
+ </sect4>
+
+ <sect4 id="type-family-overlap">
+ <title>Overlap of type synonym instances</title>
+ <para>
+ The instance declarations of a type family used in a single program
+ may only overlap if the right-hand sides of the overlapping instances
+ coincide for the overlapping types. More formally, two instance
+ declarations overlap if there is a substitution that makes the
+ left-hand sides of the instances syntactically the same. Whenever
+ that is the case, the right-hand sides of the instances must also be
+ syntactically equal under the same substitution. This condition is
+ independent of whether the type family is associated or not, and it is
+ not only a matter of consistency, but one of type safety.
+ </para>
+ <para>
+ Here are two example to illustrate the condition under which overlap
+ is permitted.
+<programlisting>
+type instance F (a, Int) = [a]
+type instance F (Int, b) = [b] -- overlap permitted
+
+type instance G (a, Int) = [a]
+type instance G (Char, a) = [a] -- ILLEGAL overlap, as [Char] /= [Int]
+</programlisting>
+ </para>
+ </sect4>
+
+ <sect4 id="type-family-decidability">
+ <title>Decidability of type synonym instances</title>
+ <para>
+ In order to guarantee that type inference in the presence of type
+ families decidable, we need to place a number of additional
+ restrictions on the formation of type instance declarations (c.f.,
+ Definition 5 (Relaxed Conditions) of “<ulink
+ url="http://www.cse.unsw.edu.au/~chak/papers/SPCS08.html">Type
+ Checking with Open Type Functions</ulink>”). Instance
+ declarations have the general form
+<programlisting>
+type instance F t1 .. tn = t
+</programlisting>
+ where we require that for every type family application <literal>(G s1
+ .. sm)</literal> in <literal>t</literal>,
+ <orderedlist>
+ <listitem>
+ <para><literal>s1 .. sm</literal> do not contain any type family
+ constructors,</para>
+ </listitem>
+ <listitem>
+ <para>the total number of symbols (data type constructors and type
+ variables) in <literal>s1 .. sm</literal> is strictly smaller than
+ in <literal>t1 .. tn</literal>, and</para>
+ </listitem>
+ <listitem>
+ <para>for every type
+ variable <literal>a</literal>, <literal>a</literal> occurs
+ in <literal>s1 .. sm</literal> at most as often as in <literal>t1
+ .. tn</literal>.</para>
+ </listitem>
+ </orderedlist>
+ These restrictions are easily verified and ensure termination of type
+ inference. However, they are not sufficient to guarantee completeness
+ of type inference in the presence of, so called, ''loopy equalities'',
+ such as <literal>a ~ [F a]</literal>, where a recursive occurrence of
+ a type variable is underneath a family application and data
+ constructor application - see the above mentioned paper for details.
+ </para>
+ <para>
+ If the option <option>-XUndecidableInstances</option> is passed to the
+ compiler, the above restrictions are not enforced and it is on the
+ programmer to ensure termination of the normalisation of type families
+ during type inference.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3 id-="equality-constraints">
+ <title>Equality constraints</title>
+ <para>
+ Type context can include equality constraints of the form <literal>t1 ~
+ t2</literal>, which denote that the types <literal>t1</literal>
+ and <literal>t2</literal> need to be the same. In the presence of type
+ families, whether two types are equal cannot generally be decided
+ locally. Hence, the contexts of function signatures may include
+ equality constraints, as in the following example:
+<programlisting>
+sumCollects :: (Collects c1, Collects c2, Elem c1 ~ Elem c2) => c1 -> c2 -> c2
+</programlisting>
+ where we require that the element type of <literal>c1</literal>
+ and <literal>c2</literal> are the same. In general, the
+ types <literal>t1</literal> and <literal>t2</literal> of an equality
+ constraint may be arbitrary monotypes; i.e., they may not contain any
+ quantifiers, independent of whether higher-rank types are otherwise
+ enabled.
+ </para>
+ <para>
+ Equality constraints can also appear in class and instance contexts.
+ The former enable a simple translation of programs using functional
+ dependencies into programs using family synonyms instead. The general
+ idea is to rewrite a class declaration of the form
+<programlisting>
+class C a b | a -> b
+</programlisting>
+ to
+<programlisting>
+class (F a ~ b) => C a b where
+ type F a
+</programlisting>
+ That is, we represent every functional dependency (FD) <literal>a1 .. an
+ -> b</literal> by an FD type family <literal>F a1 .. an</literal> and a
+ superclass context equality <literal>F a1 .. an ~ b</literal>,
+ essentially giving a name to the functional dependency. In class
+ instances, we define the type instances of FD families in accordance
+ with the class head. Method signatures are not affected by that
+ process.
+ </para>
+ <para>
+ NB: Equalities in superclass contexts are not fully implemented in
+ GHC 6.10.
+ </para>
+ </sect3>
+
+ <sect3 id-="ty-fams-in-instances">
+ <title>Type families and instance declarations</title>
+ <para>Type families require us to extend the rules for
+ the form of instance heads, which are given
+ in <xref linkend="flexible-instance-head"/>.
+ Specifically:
+<itemizedlist>
+ <listitem><para>Data type families may appear in an instance head</para></listitem>
+ <listitem><para>Type synonym families may not appear (at all) in an instance head</para></listitem>
+</itemizedlist>
+The reason for the latter restriction is that there is no way to check for. Consider