-<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>
<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:
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>
- Loading package javavm ... linking ... Overflown relocs: 4
-</programlisting>
+<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
projects / ghc-hetmet.git / blobdiff