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
  80     </sect3>
  81
  82     <sect3 id="infelicities-decls">
  83       <title>Declarations and bindings</title>
  84
  85       <para>None known.</para>
  86
  87     </sect3>
  88
  89       <sect3 id="infelicities-Modules">
  90         <title>Module system and interface files</title>
  91
  92         <variablelist>
  93           <varlistentry>
  94             <term><literal>Main</literal> module</term>
  95             <listitem>
  96               <para>GHC interprets the module header
  97 <programlisting>module Main where</programlisting>
  98               as if it was
  99 <programlisting>module Main (main) where</programlisting>
 100               </para>
 101
 102               <para>This change allows GHC to optimise slightly more
 103               aggresively inside the <literal>Main</literal>
 104               module.</para>
 105
 106               <para>You are highly unlikely to notice the difference, since
 107               importing <literal>Main</literal> is very rare (it would
 108               introduce a recursive module dependency, so doing it by
 109               accident is unlikely too).</para>
 110             </listitem>
 111           </varlistentry>
 112         </variablelist>
 113
 114     </sect3>
 115
 116     <sect3 id="infelicities-numbers">
 117       <title>Numbers, basic types, and built-in classes</title>
 118
 119       <variablelist>
 120         <varlistentry>
 121           <term>Multiply-defined array elements&mdash;not checked:</term>
 122           <listitem>
 123             <para>This code fragment <emphasis>should</emphasis>
 124             elicit a fatal error, but it does not:
 125
 126 <programlisting>
 127 main = print (array (1,1) [(1,2), (1,3)])</programlisting>
 128
 129             </para>
 130           </listitem>
 131         </varlistentry>
 132       </variablelist>
 133
 134     </sect3>
 135
 136       <sect3 id="infelicities-Prelude">
 137         <title>In <literal>Prelude</literal> support</title>
 138
 139       <variablelist>
 140         <varlistentry>
 141           <term>The <literal>Char</literal> type</term>
 142           <indexterm><primary><literal>Char</literal></primary><secondary>size
 143           of</secondary></indexterm>
 144           <listitem>
 145             <para>The Haskell report says that the
 146             <literal>Char</literal> type holds 16 bits.  GHC follows
 147             the ISO-10646 standard a little more closely:
 148             <literal>maxBound :: Char</literal> in GHC is
 149             <literal>0x10FFFF</literal>.</para>
 150           </listitem>
 151         </varlistentry>
 152
 153         <varlistentry>
 154           <term>Arbitrary-sized tuples</term>
 155           <listitem>
 156             <para>Tuples are currently limited to size 100.  HOWEVER:
 157             standard instances for tuples (<literal>Eq</literal>,
 158             <literal>Ord</literal>, <literal>Bounded</literal>,
 159             <literal>Ix</literal> <literal>Read</literal>, and
 160             <literal>Show</literal>) are available
 161             <emphasis>only</emphasis> up to 16-tuples.</para>
 162
 163             <para>This limitation is easily subvertible, so please ask
 164             if you get stuck on it.</para>
 165             </listitem>
 166           </varlistentry>
 167
 168           <varlistentry>
 169             <term><literal>Read</literal>ing integers</term>
 170             <listitem>
 171               <para>GHC's implementation of the
 172               <literal>Read</literal> class for integral types accepts
 173               hexadeciaml and octal literals (the code in the Haskell
 174               98 report doesn't).  So, for example,
 175 <programlisting>read "0xf00" :: Int</programlisting>
 176               works in GHC.</para>
 177               <para>A possible reason for this is that <literal>readLitChar</literal> accepts hex and
 178                 octal escapes, so it seems inconsistent not to do so for integers too.</para>
 179             </listitem>
 180           </varlistentry>
 181         </variablelist>
 182     </sect3>
 183   </sect2>
 184
 185   <sect2 id="haskell98-undefined">
 186     <title>GHC's interpretation of undefined behaviour in
 187     Haskell&nbsp;98</title>
 188
 189     <para>This section documents GHC's take on various issues that are
 190     left undefined or implementation specific in Haskell 98.</para>
 191
 192     <variablelist>
 193       <varlistentry>
 194         <term>Sized integral types</term>
 195         <indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
 196         </indexterm>
 197
 198         <listitem>
 199           <para>In GHC the <literal>Int</literal> type follows the
 200           size of an address on the host architecture; in other words
 201           it holds 32 bits on a 32-bit machine, and 64-bits on a
 202           64-bit machine.</para>
 203
 204           <para>Arithmetic on <literal>Int</literal> is unchecked for
 205           overflow<indexterm><primary>overflow</primary><secondary><literal>Int</literal></secondary>
 206             </indexterm>, so all operations on <literal>Int</literal> happen
 207           modulo
 208           2<superscript><replaceable>n</replaceable></superscript>
 209           where <replaceable>n</replaceable> is the size in bits of
 210           the <literal>Int</literal> type.</para>
 211
 212           <para>The <literal>fromInteger</literal><indexterm><primary><literal>fromInteger</literal></primary>
 213             </indexterm>function (and hence
 214           also <literal>fromIntegral</literal><indexterm><primary><literal>fromIntegral</literal></primary>
 215             </indexterm>) is a special case when
 216           converting to <literal>Int</literal>.  The value of
 217           <literal>fromIntegral x :: Int</literal> is given by taking
 218           the lower <replaceable>n</replaceable> bits of <literal>(abs
 219           x)</literal>, multiplied by the sign of <literal>x</literal>
 220           (in 2's complement <replaceable>n</replaceable>-bit
 221           arithmetic).  This behaviour was chosen so that for example
 222           writing <literal>0xffffffff :: Int</literal> preserves the
 223           bit-pattern in the resulting <literal>Int</literal>.</para>
 224
 225
 226            <para>Negative literals, such as <literal>-3</literal>, are
 227              specified by (a careful reading of) the Haskell Report as
 228              meaning <literal>Prelude.negate (Prelude.fromInteger 3)</literal>.
 229              So <literal>-2147483648</literal> means <literal>negate (fromInteger 2147483648)</literal>.
 230              Since <literal>fromInteger</literal> takes the lower 32 bits of the representation,
 231              <literal>fromInteger (2147483648::Integer)</literal>, computed at type <literal>Int</literal> is
 232              <literal>-2147483648::Int</literal>.  The <literal>negate</literal> operation then
 233              overflows, but it is unchecked, so <literal>negate (-2147483648::Int)</literal> is just
 234              <literal>-2147483648</literal>.  In short, one can write <literal>minBound::Int</literal> as
 235              a literal with the expected meaning (but that is not in general guaranteed.
 236              </para>
 237
 238           <para>The <literal>fromIntegral</literal> function also
 239           preserves bit-patterns when converting between the sized
 240           integral types (<literal>Int8</literal>,
 241           <literal>Int16</literal>, <literal>Int32</literal>,
 242           <literal>Int64</literal> and the unsigned
 243           <literal>Word</literal> variants), see the modules
 244           <literal>Data.Int</literal> and <literal>Data.Word</literal>
 245           in the library documentation.</para>
 246         </listitem>
 247       </varlistentry>
 248
 249       <varlistentry>
 250         <term>Unchecked float arithmetic</term>
 251         <listitem>
 252           <para>Operations on <literal>Float</literal> and
 253           <literal>Double</literal> numbers are
 254           <emphasis>unchecked</emphasis> for overflow, underflow, and
 255           other sad occurrences.  (note, however that some
 256           architectures trap floating-point overflow and
 257           loss-of-precision and report a floating-point exception,
 258           probably terminating the
 259           program)<indexterm><primary>floating-point
 260           exceptions</primary></indexterm>.</para>
 261         </listitem>
 262       </varlistentry>
 263     </variablelist>
 264
 265     </sect2>
 266   </sect1>
 267
 268
 269   <sect1 id="bugs">
 270     <title>Known bugs or infelicities</title>
 271
 272     <para>In addition to the divergences from the Haskell 98 standard
 273     listed above, GHC has the following known bugs or
 274     infelicities.</para>
 275
 276     <itemizedlist>
 277       <listitem>
 278         <para> GHC can warn about non-exhaustive or overlapping
 279         patterns (see <xref linkend="options-sanity">, and usually
 280         does so correctly.  But not always.  It gets confused by
 281         string patterns, and by guards, and can then emit bogus
 282         warnings.  The entire overlap-check code needs an overhaul
 283         really.</para>
 284       </listitem>
 285
 286       <listitem>
 287         <para>Dangers with multiple <literal>Main</literal>
 288         modules.</para>
 289
 290         <para>GHC does not insist that module <literal>Main</literal>
 291         lives in a file called <filename>Main.hs</filename>.  This is
 292         useful if you want multiple versions of
 293         <literal>Main</literal>.  But there's a danger: when compiling
 294         module <literal>Main</literal> (regardless of what file it
 295         comes from), GHC looks for the interface
 296         <filename>Main.hi</filename>; it uses this to get version
 297         information from the last time it recompiled
 298         <literal>Main</literal>.  The trouble is that this
 299         <filename>Main.hi</filename> may not correspond to the source
 300         file being compiled.</para>
 301
 302         <para>Solution: remove <filename>Main.hi</filename> first.  A
 303         better solution would be for GHC to record the source-file
 304         filename in the interface file, or even an MD5 checksum.
 305         </para>
 306       </listitem>
 307
 308       <listitem>
 309         <para>GHCi does not respect the <literal>default</literal>
 310         declaration in the module whose scope you are in.  Instead,
 311         for expressions typed at the command line, you always get the
 312         default default-type behaviour; that is,
 313         <literal>default(Int,Double)</literal>.</para>
 314
 315         <para>It would be better for GHCi to record what the default
 316         settings in each module are, and use those of the 'current'
 317         module (whatever that is).</para>
 318       </listitem>
 319
 320       <listitem>
 321         <para>GHCi does not keep careful track of what instance
 322         declarations are 'in scope' if they come from other packages.
 323         Instead, all instance declarations that GHC has seen in other
 324         packages are all in scope everywhere, whether or not the
 325         module from that package is used by the command-line
 326         expression.</para>
 327       </listitem>
 328
 329       <listitem>
 330         <para>GHC's inliner can be persuaded into non-termination
 331         using the standard way to encode recursion via a data type:</para>
 332 <programlisting>
 333   data U = MkU (U -> Bool)
 334
 335   russel :: U -> Bool
 336   russel u@(MkU p) = not $ p u
 337
 338   x :: Bool
 339   x = russel (MkU russel)
 340 </programlisting>
 341
 342         <para>We have never found another class of programs, other
 343         than this contrived one, that makes GHC diverge, and fixing
 344         the problem would impose an extra overhead on every
 345         compilation.  So the bug remains un-fixed.  There is more
 346         background in <ulink
 347         url="http://research.microsoft.com/~simonpj/Papers/inlining">
 348         Secrets of the GHC inliner</ulink>.</para>
 349       </listitem>
 350     </itemizedlist>
 351   </sect1>
 352
 353 </chapter>
 354
 355 <!-- Emacs stuff:
 356      ;;; Local Variables: ***
 357      ;;; mode: sgml ***
 358      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 359      ;;; End: ***
 360  -->