-<Chapter id="bugs-and-infelicities">
+<chapter id="bugs-and-infelicities">
<title>Known bugs and infelicities</title>
<sect1 id="vs-Haskell-defn">
<para>This section lists Glasgow Haskell infelicities in its
implementation of Haskell 98. See also the “when things
- go wrong” section (<XRef LinkEnd="wrong">) for information
+ go wrong” section (<xref linkend="wrong"/>) for information
about crashes, space leaks, and other undesirable phenomena.</para>
<para>The limitations here are listed in Haskell Report order
(let x = 42 in x == 42 == True)</programlisting>
The Haskell report is arguably wrong here, but nevertheless
- it's a difference between GHC & Haskell 98.</para>
+ it's a difference between GHC & Haskell 98.</para>
</listitem>
</itemizedlist>
</sect3>
<varlistentry>
<term>Multiply-defined array elements—not checked:</term>
<listitem>
- <para>This code fragment <emphasis>should</emphasis>
+ <para>This code fragment should
elicit a fatal error, but it does not:
<programlisting>
main = print (array (1,1) [(1,2), (1,3)])</programlisting>
-
+GHC's implemetation of <literal>array</literal> takes the value of an
+array slot from the last (index,value) pair in the list, and does no
+checking for duplicates. The reason for this is efficiency, pure and simple.
</para>
</listitem>
</varlistentry>
<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>
- </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:
</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,
for expressions typed at the command line, you always get the
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>
-<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>
+ <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
+<screen>
+Loading package javavm ... linking ... WARNING: Overflown relocation field (# relocs found: 30765)
+</screen>
+ 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>