-<Chapter id="bugs-and-infelicities">
- <title>Known bugs and infelicities
-</title>
+<chapter id="bugs-and-infelicities">
+ <title>Known bugs and infelicities</title>
-<sect1 id="vs-Haskell-defn">
- <title>Haskell 98 vs. Glasgow Haskell: language non-compliance
+ <sect1 id="vs-Haskell-defn">
+ <title>Haskell 98 vs. Glasgow Haskell: language non-compliance
</title>
-
- <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
- <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>
+
+ <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
+ <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>
<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
single qualified operator rather than the two lexemes
<literal>M</literal> and <literal>.\</literal>.</para>
</listitem>
-
- <listitem>
- <para>When <option>-fglasgow-exts</option> is on, GHC
- reserves several keywords beginning with two underscores.
- This is due to the fact that GHC uses the same lexical
- analyser for interface file parsing as it does for source
- file parsing, and these keywords are used in interface
- files. Do not use any identifiers beginning with a double
- underscore in <option>-fglasgow-exts</option> mode.</para>
- </listitem>
</itemizedlist>
</sect3>
(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>
<sect3 id="infelicities-exprs-pats">
<title>Expressions and patterns</title>
- <variablelist>
- <varlistentry>
- <term>Very long <literal>String</literal> constants:</term>
- <listitem>
- <para>May not go through. If you add a “string
- gap” every few thousand characters, then the strings
- can be as long as you like.</para>
-
- <para>Bear in mind that string gaps and the
- <option>-cpp</option><indexterm><primary><option>-cpp</option>
- </primary></indexterm> option don't mix very well (see
- <xref linkend="c-pre-processor">).</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
+ <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> Namespace pollution </term>
- <listitem>
- <para>Several modules internal to GHC are visible in the
- standard namespace. All of these modules begin with
- <literal>Prel</literal>, so the rule is: don't use any
- modules beginning with <literal>Prel</literal> in your
- program, or you may be comprehensively screwed.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
+
+ <sect3 id="infelicities-Modules">
+ <title>Module system and interface files</title>
+
+ <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>
</sect3>
<sect3 id="infelicities-Prelude">
- <title>In Prelude support</title>
+ <title>In <literal>Prelude</literal> support</title>
<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>
+ <term>Arbitrary-sized tuples</term>
<listitem>
- <para>Tuples are currently limited to size 61. HOWEVER:
+ <para>Tuples are currently limited to size 100. HOWEVER:
standard instances for tuples (<literal>Eq</literal>,
<literal>Ord</literal>, <literal>Bounded</literal>,
<literal>Ix</literal> <literal>Read</literal>, and
<literal>Show</literal>) are available
- <emphasis>only</emphasis> up to 5-tuples.</para>
+ <emphasis>only</emphasis> up to 16-tuples.</para>
<para>This limitation is easily subvertible, so please ask
if you get stuck on it.</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><literal>Read</literal>ing integers</term>
+ <listitem>
+ <para>GHC's implementation of the
+ <literal>Read</literal> class for integral types accepts
+ 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>
+ <para>A possible reason for this is that <literal>readLitChar</literal> accepts hex and
+ octal escapes, so it seems inconsistent not to do so for integers too.</para>
+ </listitem>
+ </varlistentry>
</variablelist>
</sect3>
</sect2>
<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>
</varlistentry>
</variablelist>
- </sect2>
-
-</sect1>
-
-
-<sect1 id="bugs">
- <title>Known bugs or infelicities</title>
-
-<para>GHC has the following known bugs or infelicities:
-<itemizedlist>
-
-<listitem><para>
-GHC only provides tuples up to size 62, and derived tuple instances (for
-Eq, Ord, etc) up to size 15.
-</para></listitem>
-
-<listitem><para>
-GHC can warn about non-exhaustive or overlapping patterns, 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 really.
-</para></listitem>
-
-
-
-<listitem><para>Dangers with multiple Main 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></listitem>
-
-<listitem><para>
-GHC's inliner can be persuaded into non-termination using the standard way to encode
-recursion via a data type:
+ </sect2>
+ </sect1>
+
+
+ <sect1 id="bugs">
+ <title>Known bugs or infelicities</title>
+
+ <para>In addition to the divergences from the Haskell 98 standard
+ 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
+ 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
+ really.</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:
+<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)
x :: Bool
x = russel (MkU russel)
</programlisting>
-We have never found another program, 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></para>
-</sect1>
-
-</Chapter>
+
+ <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
+ 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>
<!-- Emacs stuff:
;;; Local Variables: ***
projects / ghc-hetmet.git / blobdiff