<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">
<variablelist>
<varlistentry>
- <term>The <literal>Char</literal> type</term>
- <indexterm><primary><literal>Char</literal></primary><secondary>size
- of</secondary></indexterm>
- <listitem>
- <para>The Haskell report says that the
- <literal>Char</literal> type holds 16 bits. GHC follows
- the ISO-10646 standard a little more closely:
- <literal>maxBound :: Char</literal> in GHC is
- <literal>0x10FFFF</literal>.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term>Arbitrary-sized tuples</term>
<listitem>
<para>Tuples are currently limited to size 100. HOWEVER:
<listitem>
<para>GHC's implementation of the
<literal>Read</literal> class for integral types accepts
- hexadeciaml and octal literals (the code in the Haskell
+ hexadecimal and octal literals (the code in the Haskell
98 report doesn't). So, for example,
<programlisting>read "0xf00" :: Int</programlisting>
works in GHC.</para>
<variablelist>
<varlistentry>
+ <term>The <literal>Char</literal> type</term>
+ <indexterm><primary><literal>Char</literal></primary><secondary>size
+ of</secondary></indexterm>
+ <listitem>
+ <para>Following the ISO-10646 standard,
+ <literal>maxBound :: Char</literal> in GHC is
+ <literal>0x10FFFF</literal>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>Sized integral types</term>
<indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
</indexterm>
listed above, GHC has the following known bugs or
infelicities.</para>
+ <sect2 id="bugs-ghc">
+ <title>Bugs in GHC</title>
+
<itemizedlist>
<listitem>
<para> GHC can warn about non-exhaustive or overlapping
- patterns (see <xref linkend="options-sanity">, and usually
+ patterns (see <xref linkend="options-sanity">), and usually
does so correctly. But not always. It gets confused by
string patterns, and by guards, and can then emit bogus
warnings. The entire overlap-check code needs an overhaul
</listitem>
<listitem>
- <para>Dangers with multiple <literal>Main</literal>
- modules.</para>
-
- <para>GHC does not insist that module <literal>Main</literal>
- lives in a file called <filename>Main.hs</filename>. This is
- useful if you want multiple versions of
- <literal>Main</literal>. But there's a danger: when compiling
- module <literal>Main</literal> (regardless of what file it
- comes from), GHC looks for the interface
- <filename>Main.hi</filename>; it uses this to get version
- information from the last time it recompiled
- <literal>Main</literal>. The trouble is that this
- <filename>Main.hi</filename> may not correspond to the source
- file being compiled.</para>
-
- <para>Solution: remove <filename>Main.hi</filename> first. A
- better solution would be for GHC to record the source-file
- filename in the interface file, or even an MD5 checksum.
- </para>
+ <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>GHC's inliner can be persuaded into non-termination
+ using the standard way to encode recursion via a data type:</para>
+<programlisting>
+ data U = MkU (U -> Bool)
+
+ russel :: U -> Bool
+ russel u@(MkU p) = not $ p u
+
+ x :: Bool
+ x = russel (MkU russel)
+</programlisting>
+
+ <para>We have never found another class of programs, other
+ than this contrived one, that makes GHC diverge, and fixing
+ the problem would impose an extra overhead on every
+ compilation. So the bug remains un-fixed. There is more
+ background in <ulink
+ url="http://research.microsoft.com/~simonpj/Papers/inlining">
+ Secrets of the GHC inliner</ulink>.</para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2 id="bugs-ghci">
+ <title>Bugs in GHCi (the interactive GHC)</title>
+ <itemizedlist>
<listitem>
<para>GHCi does not respect the <literal>default</literal>
declaration in the module whose scope you are in. Instead,
expression.</para>
</listitem>
- <listitem>
- <para>GHC's inliner can be persuaded into non-termination
- using the standard way to encode recursion via a data type:</para>
+ <listitem>
+ <para>On Windows, there's a GNU ld/BFD bug
+ whereby it emits bogus PE object files that have more than
+ 0xffff relocations. When GHCi tries to load a package affected by this
+ bug, you get an error message of the form
<programlisting>
- data U = MkU (U -> Bool)
-
- russel :: U -> Bool
- russel u@(MkU p) = not $ p u
-
- x :: Bool
- x = russel (MkU russel)
+ Loading package javavm ... linking ... Overflown relocs: 4
</programlisting>
-
- <para>We have never found another class of programs, other
- than this contrived one, that makes GHC diverge, and fixing
- the problem would impose an extra overhead on every
- compilation. So the bug remains un-fixed. There is more
- background in <ulink
- url="http://research.microsoft.com/~simonpj/Papers/inlining">
- Secrets of the GHC inliner</ulink>.</para>
+ The last time we looked, this bug still
+ wasn't fixed in the BFD codebase, and there wasn't any
+ noticeable interest in fixing it when we reported the bug
+ back in 2001 or so.
+ </para>
+ <para>The workaround is to split up the .o files that make up
+ your package into two or more .o's, along the lines of
+ how the "base" package does it.</para>
</listitem>
</itemizedlist>
+ </sect2>
</sect1>
</chapter>
projects / ghc-hetmet.git / blobdiff