generated by the call to <literal>elem</literal>, so that the type of
<literal>insert</literal> itself has no <literal>Eq</literal> constraint.
</para>
generated by the call to <literal>elem</literal>, so that the type of
<literal>insert</literal> itself has no <literal>Eq</literal> constraint.
</para>
<para>
At the moment, record updates are not yet possible with GADT-style declarations,
so support is limited to record construction, selection and pattern matching.
<para>
At the moment, record updates are not yet possible with GADT-style declarations,
so support is limited to record construction, selection and pattern matching.
<para>
GHC takes a conservative position: it accepts the first two, but not the third. The rule is this:
each constraint in the inferred instance context must consist only of type variables,
<para>
GHC takes a conservative position: it accepts the first two, but not the third. The rule is this:
each constraint in the inferred instance context must consist only of type variables,
deriving instance MonadState Int Foo
</programlisting>
GHC always treats the <emphasis>last</emphasis> parameter of the instance
deriving instance MonadState Int Foo
</programlisting>
GHC always treats the <emphasis>last</emphasis> parameter of the instance
The willingness to be overlapped or incoherent is a property of
the <emphasis>instance declaration</emphasis> itself, controlled by the
presence or otherwise of the <option>-XOverlappingInstances</option>
The willingness to be overlapped or incoherent is a property of
the <emphasis>instance declaration</emphasis> itself, controlled by the
presence or otherwise of the <option>-XOverlappingInstances</option>
being defined. Neither flag is required in a module that imports and uses the
instance declaration. Specifically, during the lookup process:
<itemizedlist>
being defined. Neither flag is required in a module that imports and uses the
instance declaration. Specifically, during the lookup process:
<itemizedlist>
right-hand side, so the implicit parameter <literal>?acc</literal> is not
passed to the recursive call. In the latter case, because <literal>len_acc2</literal>
has a type signature, the recursive call is made to the
right-hand side, so the implicit parameter <literal>?acc</literal> is not
passed to the recursive call. In the latter case, because <literal>len_acc2</literal>
has a type signature, the recursive call is made to the
<itemizedlist>
<listitem> <para> '<literal>?x</literal>' and '<literal>%x</literal>'
are entirely distinct implicit parameters: you
<itemizedlist>
<listitem> <para> '<literal>?x</literal>' and '<literal>%x</literal>'
are entirely distinct implicit parameters: you
design.)</para></listitem>
<listitem><para>Furthermore, distinct lexical type variables stand for distinct
type variables. This means that every programmer-written type signature
design.)</para></listitem>
<listitem><para>Furthermore, distinct lexical type variables stand for distinct
type variables. This means that every programmer-written type signature
<emphasis>rigid</emphasis> type; that is, the type is fully known to the type
checker, and no inference is involved.</para></listitem>
<listitem><para>Lexical type variables may be alpha-renamed freely, without
<emphasis>rigid</emphasis> type; that is, the type is fully known to the type
checker, and no inference is involved.</para></listitem>
<listitem><para>Lexical type variables may be alpha-renamed freely, without
g (x::a) = x
h ((x,y) :: (Int,Bool)) = (y,x)
</programlisting>
g (x::a) = x
h ((x,y) :: (Int,Bool)) = (y,x)
</programlisting>
already in scope (i.e. bound by the enclosing context), matters are simple: the
signature simply constrains the type of the pattern in the obvious way.
</para>
already in scope (i.e. bound by the enclosing context), matters are simple: the
signature simply constrains the type of the pattern in the obvious way.
</para>
<para>
If this seems a little odd, we think so too. But we must have
<emphasis>some</emphasis> way to bring such type variables into scope, else we
<para>
If this seems a little odd, we think so too. But we must have
<emphasis>some</emphasis> way to bring such type variables into scope, else we
<literal>g</literal> is typechecked first, separately from that for
<literal>f</literal>,
because the reference to <literal>f</literal> in <literal>g</literal>'s right
<literal>g</literal> is typechecked first, separately from that for
<literal>f</literal>,
because the reference to <literal>f</literal> in <literal>g</literal>'s right
type is generalised, to get
<programlisting>
g :: Ord a => a -> Bool
</programlisting>
type is generalised, to get
<programlisting>
g :: Ord a => a -> Bool
</programlisting>
<para>Then compile it again with <option>-prof</option>, and
additionally use <option>-osuf
p_o</option><indexterm><primary><option>-osuf</option></primary></indexterm>
<para>Then compile it again with <option>-prof</option>, and
additionally use <option>-osuf
p_o</option><indexterm><primary><option>-osuf</option></primary></indexterm>
that isn't the normal object suffix here). GHC will automatically
load the object files built in the first step when executing splice
expressions. If you omit the <option>-osuf</option> flag when
that isn't the normal object suffix here). GHC will automatically
load the object files built in the first step when executing splice
expressions. If you omit the <option>-osuf</option> flag when
g7 x = case f x of { !y -> body }
</programlisting>
The functions <literal>g5</literal> and <literal>g6</literal> mean exactly the same thing.
g7 x = case f x of { !y -> body }
</programlisting>
The functions <literal>g5</literal> and <literal>g6</literal> mean exactly the same thing.
result, and then evaluates <literal>body</literal>.
</para><para>
Bang patterns work in <literal>let</literal> and <literal>where</literal>
result, and then evaluates <literal>body</literal>.
</para><para>
Bang patterns work in <literal>let</literal> and <literal>where</literal>
<para>When you compile any module that imports and uses any
of the specified entities, GHC will print the specified
message.</para>
<para>When you compile any module that imports and uses any
of the specified entities, GHC will print the specified
message.</para>
being compiled, and you can only use unqualified names in the list of
entities being deprecated. A capitalised name, such as <literal>T</literal>
refers to <emphasis>either</emphasis> the type constructor <literal>T</literal>
being compiled, and you can only use unqualified names in the list of
entities being deprecated. A capitalised name, such as <literal>T</literal>
refers to <emphasis>either</emphasis> the type constructor <literal>T</literal>
<para>A <literal>SPECIALIZE</literal> pragma can optionally be followed with a
<literal>INLINE</literal> or <literal>NOINLINE</literal> pragma, optionally
followed by a phase, as described in <xref linkend="inline-noinline-pragma"/>.
<para>A <literal>SPECIALIZE</literal> pragma can optionally be followed with a
<literal>INLINE</literal> or <literal>NOINLINE</literal> pragma, optionally
followed by a phase, as described in <xref linkend="inline-noinline-pragma"/>.
are now described in the module <ulink
url="../libraries/base/GHC-Prim.html"><literal>GHC.Prim</literal></ulink>
in the library documentation.</para>
are now described in the module <ulink
url="../libraries/base/GHC-Prim.html"><literal>GHC.Prim</literal></ulink>
in the library documentation.</para>
implementing the necessary bidirectional maps over arbitrary type constructors.
It would be relatively easy to add specific type constructors, such as Maybe and list,
to the ones that are allowed.</para>
implementing the necessary bidirectional maps over arbitrary type constructors.
It would be relatively easy to add specific type constructors, such as Maybe and list,
to the ones that are allowed.</para>