ghc/docs/users_guide/bugs.sgml

   1 <Chapter id="bugs-and-infelicities">
   2   <title>Known bugs and infelicities</title>
   3
   4   <sect1 id="vs-Haskell-defn">
   5     <title>Haskell&nbsp;98 vs.&nbsp;Glasgow Haskell: language non-compliance
   6 </title>
   7
   8     <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
   9     <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>
  10
  11   <para>This section lists Glasgow Haskell infelicities in its
  12   implementation of Haskell&nbsp;98.  See also the &ldquo;when things
  13   go wrong&rdquo; section (<XRef LinkEnd="wrong">) for information
  14   about crashes, space leaks, and other undesirable phenomena.</para>
  15
  16   <para>The limitations here are listed in Haskell Report order
  17   (roughly).</para>
  18
  19   <sect2 id="haskell98-divergence">
  20     <title>Divergence from Haskell&nbsp;98</title>
  21
  22
  23     <sect3 id="infelicities-lexical">
  24       <title>Lexical syntax</title>
  25
  26       <itemizedlist>
  27         <listitem>
  28           <para>The Haskell report specifies that programs may be
  29           written using Unicode.  GHC only accepts the ISO-8859-1
  30           character set at the moment.</para>
  31         </listitem>
  32
  33         <listitem>
  34           <para>Certain lexical rules regarding qualified identifiers
  35           are slightly different in GHC compared to the Haskell
  36           report.  When you have
  37           <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
  38           such as <literal>M.\</literal>, GHC will interpret it as a
  39           single qualified operator rather than the two lexemes
  40           <literal>M</literal> and <literal>.\</literal>.</para>
  41         </listitem>
  42       </itemizedlist>
  43     </sect3>
  44
  45       <sect3 id="infelicities-syntax">
  46         <title>Context-free syntax</title>
  47
  48       <itemizedlist>
  49         <listitem>
  50           <para>GHC doesn't do fixity resolution in expressions during
  51           parsing.  For example, according to the Haskell report, the
  52           following expression is legal Haskell:
  53 <programlisting>
  54     let x = 42 in x == 42 == True</programlisting>
  55         and parses as:
  56 <programlisting>
  57     (let x = 42 in x == 42) == True</programlisting>
  58
  59           because according to the report, the <literal>let</literal>
  60           expression <quote>extends as far to the right as
  61           possible</quote>.  Since it can't extend past the second
  62           equals sign without causing a parse error
  63           (<literal>==</literal> is non-fix), the
  64           <literal>let</literal>-expression must terminate there.  GHC
  65           simply gobbles up the whole expression, parsing like this:
  66 <programlisting>
  67     (let x = 42 in x == 42 == True)</programlisting>
  68
  69           The Haskell report is arguably wrong here, but nevertheless
  70           it's a difference between GHC & Haskell 98.</para>
  71         </listitem>
  72       </itemizedlist>
  73     </sect3>
  74
  75   <sect3 id="infelicities-exprs-pats">
  76       <title>Expressions and patterns</title>
  77
  78         <para>None known.</para>
  79     </sect3>
  80
  81     <sect3 id="infelicities-decls">
  82       <title>Declarations and bindings</title>
  83
  84       <para>None known.</para>
  85     </sect3>
  86
  87       <sect3 id="infelicities-Modules">
  88         <title>Module system and interface files</title>
  89
  90         <para>None known.</para>
  91     </sect3>
  92
  93     <sect3 id="infelicities-numbers">
  94       <title>Numbers, basic types, and built-in classes</title>
  95
  96       <variablelist>
  97         <varlistentry>
  98           <term>Multiply-defined array elements&mdash;not checked:</term>
  99           <listitem>
 100             <para>This code fragment <emphasis>should</emphasis>
 101             elicit a fatal error, but it does not:
 102
 103 <programlisting>
 104 main = print (array (1,1) [(1,2), (1,3)])</programlisting>
 105
 106             </para>
 107           </listitem>
 108         </varlistentry>
 109       </variablelist>
 110
 111     </sect3>
 112
 113       <sect3 id="infelicities-Prelude">
 114         <title>In <literal>Prelude</literal> support</title>
 115
 116       <variablelist>
 117         <varlistentry>
 118           <term>The <literal>Char</literal> type</term>
 119           <indexterm><primary><literal>Char</literal></primary><secondary>size
 120           of</secondary></indexterm>
 121           <listitem>
 122             <para>The Haskell report says that the
 123             <literal>Char</literal> type holds 16 bits.  GHC follows
 124             the ISO-10646 standard a little more closely:
 125             <literal>maxBound :: Char</literal> in GHC is
 126             <literal>0x10FFFF</literal>.</para>
 127           </listitem>
 128         </varlistentry>
 129
 130         <varlistentry>
 131           <term>Arbitrary-sized tuples</term>
 132           <listitem>
 133             <para>Tuples are currently limited to size 100.  HOWEVER:
 134             standard instances for tuples (<literal>Eq</literal>,
 135             <literal>Ord</literal>, <literal>Bounded</literal>,
 136             <literal>Ix</literal> <literal>Read</literal>, and
 137             <literal>Show</literal>) are available
 138             <emphasis>only</emphasis> up to 16-tuples.</para>
 139
 140             <para>This limitation is easily subvertible, so please ask
 141             if you get stuck on it.</para>
 142             </listitem>
 143           </varlistentry>
 144
 145           <varlistentry>
 146             <term><literal>Read</literal>ing integers</term>
 147             <listitem>
 148               <para>GHC's implementation of the
 149               <literal>Read</literal> class for integral types accepts
 150               hexadeciaml and octal literals (the code in the Haskell
 151               98 report doesn't).  So, for example,
 152 <programlisting>read "0xf00" :: Int</programlisting>
 153               works in GHC.</para>
 154               <para>A possible reason for this is that <literal>readLitChar</literal> accepts hex and
 155                 octal escapes, so it seems inconsistent not to do so for integers too.</para>
 156             </listitem>
 157           </varlistentry>
 158         </variablelist>
 159     </sect3>
 160   </sect2>
 161
 162   <sect2 id="haskell98-undefined">
 163     <title>GHC's interpretation of undefined behaviour in
 164     Haskell&nbsp;98</title>
 165
 166     <para>This section documents GHC's take on various issues that are
 167     left undefined or implementation specific in Haskell 98.</para>
 168
 169     <variablelist>
 170       <varlistentry>
 171         <term>Sized integral types</term>
 172         <indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
 173         </indexterm>
 174
 175         <listitem>
 176           <para>In GHC the <literal>Int</literal> type follows the
 177           size of an address on the host architecture; in other words
 178           it holds 32 bits on a 32-bit machine, and 64-bits on a
 179           64-bit machine.</para>
 180
 181           <para>Arithmetic on <literal>Int</literal> is unchecked for
 182           overflow<indexterm><primary>overflow</primary><secondary><literal>Int</literal></secondary>
 183             </indexterm>, so all operations on <literal>Int</literal> happen
 184           modulo
 185           2<superscript><replaceable>n</replaceable></superscript>
 186           where <replaceable>n</replaceable> is the size in bits of
 187           the <literal>Int</literal> type.</para>
 188
 189           <para>The <literal>fromInteger</literal><indexterm><primary><literal>fromInteger</literal></primary>
 190             </indexterm>function (and hence
 191           also <literal>fromIntegral</literal><indexterm><primary><literal>fromIntegral</literal></primary>
 192             </indexterm>) is a special case when
 193           converting to <literal>Int</literal>.  The value of
 194           <literal>fromIntegral x :: Int</literal> is given by taking
 195           the lower <replaceable>n</replaceable> bits of <literal>(abs
 196           x)</literal>, multiplied by the sign of <literal>x</literal>
 197           (in 2's complement <replaceable>n</replaceable>-bit
 198           arithmetic).  This behaviour was chosen so that for example
 199           writing <literal>0xffffffff :: Int</literal> preserves the
 200           bit-pattern in the resulting <literal>Int</literal>.</para>
 201
 202
 203            <para>Negative literals, such as <literal>-3</literal>, are
 204              specified by (a careful reading of) the Haskell Report as
 205              meaning <literal>Prelude.negate (Prelude.fromInteger 3)</literal>.
 206              So <literal>-2147483648</literal> means <literal>negate (fromInteger 2147483648)</literal>.
 207              Since <literal>fromInteger</literal> takes the lower 32 bits of the representation,
 208              <literal>fromInteger (2147483648::Integer)</literal>, computed at type <literal>Int</literal> is
 209              <literal>-2147483648::Int</literal>.  The <literal>negate</literal> operation then
 210              overflows, but it is unchecked, so <literal>negate (-2147483648::Int)</literal> is just
 211              <literal>-2147483648</literal>.  In short, one can write <literal>minBound::Int</literal> as
 212              a literal with the expected meaning (but that is not in general guaranteed.
 213              </para>
 214
 215           <para>The <literal>fromIntegral</literal> function also
 216           preserves bit-patterns when converting between the sized
 217           integral types (<literal>Int8</literal>,
 218           <literal>Int16</literal>, <literal>Int32</literal>,
 219           <literal>Int64</literal> and the unsigned
 220           <literal>Word</literal> variants), see the modules
 221           <literal>Data.Int</literal> and <literal>Data.Word</literal>
 222           in the library documentation.</para>
 223         </listitem>
 224       </varlistentry>
 225
 226       <varlistentry>
 227         <term>Unchecked float arithmetic</term>
 228         <listitem>
 229           <para>Operations on <literal>Float</literal> and
 230           <literal>Double</literal> numbers are
 231           <emphasis>unchecked</emphasis> for overflow, underflow, and
 232           other sad occurrences.  (note, however that some
 233           architectures trap floating-point overflow and
 234           loss-of-precision and report a floating-point exception,
 235           probably terminating the
 236           program)<indexterm><primary>floating-point
 237           exceptions</primary></indexterm>.</para>
 238         </listitem>
 239       </varlistentry>
 240     </variablelist>
 241
 242     </sect2>
 243   </sect1>
 244
 245
 246   <sect1 id="bugs">
 247     <title>Known bugs or infelicities</title>
 248
 249     <para>In addition to the divergences from the Haskell 98 standard
 250     listed above, GHC has the following known bugs or
 251     infelicities.</para>
 252
 253   <sect2 id="bugs-ghc">
 254     <title>Bugs in GHC</title>
 255
 256     <itemizedlist>
 257       <listitem>
 258         <para> GHC can warn about non-exhaustive or overlapping
 259         patterns (see <xref linkend="options-sanity">), and usually
 260         does so correctly.  But not always.  It gets confused by
 261         string patterns, and by guards, and can then emit bogus
 262         warnings.  The entire overlap-check code needs an overhaul
 263         really.</para>
 264       </listitem>
 265
 266       <listitem>
 267         <para>GHC does not allow you to have a data type with a context
 268            that mentions type variables that are not data type parameters.
 269           For example:
 270 <programlisting>
 271   data C a b => T a = MkT a
 272 </programlisting>
 273           so that <literal>MkT</literal>'s type is
 274 <programlisting>
 275   MkT :: forall a b. C a b => a -> T a
 276 </programlisting>
 277         In principle, with a suitable class declaration with a functional dependency,
 278          it's possible that this type is not ambiguous; but GHC nevertheless rejects
 279           it.  The type variables mentioned in the context of the data type declaration must
 280         be among the type parameters of the data type.</para>
 281       </listitem>
 282
 283       <listitem>
 284         <para>GHC's inliner can be persuaded into non-termination
 285         using the standard way to encode recursion via a data type:</para>
 286 <programlisting>
 287   data U = MkU (U -> Bool)
 288
 289   russel :: U -> Bool
 290   russel u@(MkU p) = not $ p u
 291
 292   x :: Bool
 293   x = russel (MkU russel)
 294 </programlisting>
 295
 296         <para>We have never found another class of programs, other
 297         than this contrived one, that makes GHC diverge, and fixing
 298         the problem would impose an extra overhead on every
 299         compilation.  So the bug remains un-fixed.  There is more
 300         background in <ulink
 301         url="http://research.microsoft.com/~simonpj/Papers/inlining">
 302         Secrets of the GHC inliner</ulink>.</para>
 303       </listitem>
 304     </itemizedlist>
 305   </sect2>
 306
 307   <sect2 id="bugs-ghci">
 308     <title>Bugs in GHCi (the interactive GHC)</title>
 309     <itemizedlist>
 310       <listitem>
 311         <para>GHCi does not respect the <literal>default</literal>
 312         declaration in the module whose scope you are in.  Instead,
 313         for expressions typed at the command line, you always get the
 314         default default-type behaviour; that is,
 315         <literal>default(Int,Double)</literal>.</para>
 316
 317         <para>It would be better for GHCi to record what the default
 318         settings in each module are, and use those of the 'current'
 319         module (whatever that is).</para>
 320       </listitem>
 321
 322       <listitem>
 323         <para>GHCi does not keep careful track of what instance
 324         declarations are 'in scope' if they come from other packages.
 325         Instead, all instance declarations that GHC has seen in other
 326         packages are all in scope everywhere, whether or not the
 327         module from that package is used by the command-line
 328         expression.</para>
 329       </listitem>
 330
 331       <listitem>
 332       <para>On Windows, there's a GNU ld/BFD bug
 333       whereby it emits bogus PE object files that have more than
 334       0xffff relocations. When GHCi tries to load a package affected by this
 335       bug, you get an error message of the form
 336 <programlisting>
 337   Loading package javavm ... linking ... Overflown relocs: 4
 338 </programlisting>
 339       The last time we looked, this bug still
 340       wasn't fixed in the BFD codebase, and there wasn't any
 341       noticeable interest in fixing it when we reported the bug
 342       back in 2001 or so.
 343       </para>
 344       <para>The workaround is to split up the .o files that make up
 345       your package into two or more .o's, along the lines of
 346       how the "base" package does it.</para>
 347       </listitem>
 348     </itemizedlist>
 349   </sect2>
 350   </sect1>
 351
 352 </chapter>
 353
 354 <!-- Emacs stuff:
 355      ;;; Local Variables: ***
 356      ;;; mode: sgml ***
 357      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 358      ;;; End: ***
 359  -->