<title>Expressions and patterns</title>
<para>None known.</para>
-
</sect3>
<sect3 id="infelicities-decls">
<title>Declarations and bindings</title>
<para>None known.</para>
-
</sect3>
<sect3 id="infelicities-Modules">
<title>Module system and interface files</title>
- <variablelist>
- <varlistentry>
- <term><literal>Main</literal> module</term>
- <listitem>
- <para>GHC interprets the module header
-<programlisting>module Main where</programlisting>
- as if it was
-<programlisting>module Main (main) where</programlisting>
- </para>
-
- <para>This change allows GHC to optimise slightly more
- aggresively inside the <literal>Main</literal>
- module.</para>
-
- <para>You are highly unlikely to notice the difference, since
- importing <literal>Main</literal> is very rare (it would
- introduce a recursive module dependency, so doing it by
- accident is unlikely too).</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
+ <para>None known.</para>
</sect3>
<sect3 id="infelicities-numbers">
</listitem>
<listitem>
+ <para>GHC does not allow you to have a data type with a context
+ that mentions type variables that are not data type parameters.
+ For example:
+<programlisting>
+ data C a b => T a = MkT a
+</programlisting>
+ so that <literal>MkT</literal>'s type is
+<programlisting>
+ MkT :: forall a b. C a b => a -> T a
+</programlisting>
+ In principle, with a suitable class declaration with a functional dependency,
+ it's possible that this type is not ambiguous; but GHC nevertheless rejects
+ it. The type variables mentioned in the context of the data type declaration must
+ be among the type parameters of the data type.</para>
+ </listitem>
+
+ <listitem>
<para>GHCi does not respect the <literal>default</literal>
declaration in the module whose scope you are in. Instead,
for expressions typed at the command line, you always get the