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     <itemizedlist>
 254       <listitem>
 255         <para> GHC can warn about non-exhaustive or overlapping
 256         patterns (see <xref linkend="options-sanity">, and usually
 257         does so correctly.  But not always.  It gets confused by
 258         string patterns, and by guards, and can then emit bogus
 259         warnings.  The entire overlap-check code needs an overhaul
 260         really.</para>
 261       </listitem>
 262
 263       <listitem>
 264         <para>Dangers with multiple <literal>Main</literal>
 265         modules.</para>
 266
 267         <para>GHC does not insist that module <literal>Main</literal>
 268         lives in a file called <filename>Main.hs</filename>.  This is
 269         useful if you want multiple versions of
 270         <literal>Main</literal>.  But there's a danger: when compiling
 271         module <literal>Main</literal> (regardless of what file it
 272         comes from), GHC looks for the interface
 273         <filename>Main.hi</filename>; it uses this to get version
 274         information from the last time it recompiled
 275         <literal>Main</literal>.  The trouble is that this
 276         <filename>Main.hi</filename> may not correspond to the source
 277         file being compiled.</para>
 278
 279         <para>Solution: remove <filename>Main.hi</filename> first.  A
 280         better solution would be for GHC to record the source-file
 281         filename in the interface file, or even an MD5 checksum.
 282         </para>
 283       </listitem>
 284
 285       <listitem>
 286         <para>GHCi does not respect the <literal>default</literal>
 287         declaration in the module whose scope you are in.  Instead,
 288         for expressions typed at the command line, you always get the
 289         default default-type behaviour; that is,
 290         <literal>default(Int,Double)</literal>.</para>
 291
 292         <para>It would be better for GHCi to record what the default
 293         settings in each module are, and use those of the 'current'
 294         module (whatever that is).</para>
 295       </listitem>
 296
 297       <listitem>
 298         <para>GHCi does not keep careful track of what instance
 299         declarations are 'in scope' if they come from other packages.
 300         Instead, all instance declarations that GHC has seen in other
 301         packages are all in scope everywhere, whether or not the
 302         module from that package is used by the command-line
 303         expression.</para>
 304       </listitem>
 305
 306       <listitem>
 307         <para>GHC's inliner can be persuaded into non-termination
 308         using the standard way to encode recursion via a data type:</para>
 309 <programlisting>
 310   data U = MkU (U -> Bool)
 311
 312   russel :: U -> Bool
 313   russel u@(MkU p) = not $ p u
 314
 315   x :: Bool
 316   x = russel (MkU russel)
 317 </programlisting>
 318
 319         <para>We have never found another class of programs, other
 320         than this contrived one, that makes GHC diverge, and fixing
 321         the problem would impose an extra overhead on every
 322         compilation.  So the bug remains un-fixed.  There is more
 323         background in <ulink
 324         url="http://research.microsoft.com/~simonpj/Papers/inlining">
 325         Secrets of the GHC inliner</ulink>.</para>
 326       </listitem>
 327     </itemizedlist>
 328   </sect1>
 329
 330 </chapter>
 331
 332 <!-- Emacs stuff:
 333      ;;; Local Variables: ***
 334      ;;; mode: sgml ***
 335      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 336      ;;; End: ***
 337  -->