-<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>
<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">
<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>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
- default default-type behaviour; that is,
- <literal>default(Int,Double)</literal>.</para>
-
- <para>It would be better for GHCi to record what the default
- settings in each module are, and use those of the 'current'
- module (whatever that is).</para>
- </listitem>
-
- <listitem>
- <para>GHCi does not keep careful track of what instance
- declarations are 'in scope' if they come from other packages.
- Instead, all instance declarations that GHC has seen in other
- packages are all in scope everywhere, whether or not the
- module from that package is used by the command-line
- expression.</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>
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
+ default default-type behaviour; that is,
+ <literal>default(Int,Double)</literal>.</para>
+
+ <para>It would be better for GHCi to record what the default
+ settings in each module are, and use those of the 'current'
+ module (whatever that is).</para>
+ </listitem>
+
+ <listitem>
+ <para>GHCi does not keep careful track of what instance
+ declarations are 'in scope' if they come from other packages.
+ Instead, all instance declarations that GHC has seen in other
+ packages are all in scope everywhere, whether or not the
+ module from that package is used by the command-line
+ expression.</para>
+ </listitem>
+
+ <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>
projects / ghc-hetmet.git / blobdiff