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>Arbitrary-sized tuples</term>
 119           <listitem>
 120             <para>Tuples are currently limited to size 100.  HOWEVER:
 121             standard instances for tuples (<literal>Eq</literal>,
 122             <literal>Ord</literal>, <literal>Bounded</literal>,
 123             <literal>Ix</literal> <literal>Read</literal>, and
 124             <literal>Show</literal>) are available
 125             <emphasis>only</emphasis> up to 16-tuples.</para>
 126
 127             <para>This limitation is easily subvertible, so please ask
 128             if you get stuck on it.</para>
 129             </listitem>
 130           </varlistentry>
 131
 132           <varlistentry>
 133             <term><literal>Read</literal>ing integers</term>
 134             <listitem>
 135               <para>GHC's implementation of the
 136               <literal>Read</literal> class for integral types accepts
 137               hexadecimal and octal literals (the code in the Haskell
 138               98 report doesn't).  So, for example,
 139 <programlisting>read "0xf00" :: Int</programlisting>
 140               works in GHC.</para>
 141               <para>A possible reason for this is that <literal>readLitChar</literal> accepts hex and
 142                 octal escapes, so it seems inconsistent not to do so for integers too.</para>
 143             </listitem>
 144           </varlistentry>
 145         </variablelist>
 146     </sect3>
 147   </sect2>
 148
 149   <sect2 id="haskell98-undefined">
 150     <title>GHC's interpretation of undefined behaviour in
 151     Haskell&nbsp;98</title>
 152
 153     <para>This section documents GHC's take on various issues that are
 154     left undefined or implementation specific in Haskell 98.</para>
 155
 156     <variablelist>
 157       <varlistentry>
 158         <term>The <literal>Char</literal> type</term>
 159         <indexterm><primary><literal>Char</literal></primary><secondary>size
 160         of</secondary></indexterm>
 161         <listitem>
 162           <para>Following the ISO-10646 standard,
 163           <literal>maxBound :: Char</literal> in GHC is
 164           <literal>0x10FFFF</literal>.</para>
 165         </listitem>
 166       </varlistentry>
 167
 168       <varlistentry>
 169         <term>Sized integral types</term>
 170         <indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
 171         </indexterm>
 172
 173         <listitem>
 174           <para>In GHC the <literal>Int</literal> type follows the
 175           size of an address on the host architecture; in other words
 176           it holds 32 bits on a 32-bit machine, and 64-bits on a
 177           64-bit machine.</para>
 178
 179           <para>Arithmetic on <literal>Int</literal> is unchecked for
 180           overflow<indexterm><primary>overflow</primary><secondary><literal>Int</literal></secondary>
 181             </indexterm>, so all operations on <literal>Int</literal> happen
 182           modulo
 183           2<superscript><replaceable>n</replaceable></superscript>
 184           where <replaceable>n</replaceable> is the size in bits of
 185           the <literal>Int</literal> type.</para>
 186
 187           <para>The <literal>fromInteger</literal><indexterm><primary><literal>fromInteger</literal></primary>
 188             </indexterm>function (and hence
 189           also <literal>fromIntegral</literal><indexterm><primary><literal>fromIntegral</literal></primary>
 190             </indexterm>) is a special case when
 191           converting to <literal>Int</literal>.  The value of
 192           <literal>fromIntegral x :: Int</literal> is given by taking
 193           the lower <replaceable>n</replaceable> bits of <literal>(abs
 194           x)</literal>, multiplied by the sign of <literal>x</literal>
 195           (in 2's complement <replaceable>n</replaceable>-bit
 196           arithmetic).  This behaviour was chosen so that for example
 197           writing <literal>0xffffffff :: Int</literal> preserves the
 198           bit-pattern in the resulting <literal>Int</literal>.</para>
 199
 200
 201            <para>Negative literals, such as <literal>-3</literal>, are
 202              specified by (a careful reading of) the Haskell Report as
 203              meaning <literal>Prelude.negate (Prelude.fromInteger 3)</literal>.
 204              So <literal>-2147483648</literal> means <literal>negate (fromInteger 2147483648)</literal>.
 205              Since <literal>fromInteger</literal> takes the lower 32 bits of the representation,
 206              <literal>fromInteger (2147483648::Integer)</literal>, computed at type <literal>Int</literal> is
 207              <literal>-2147483648::Int</literal>.  The <literal>negate</literal> operation then
 208              overflows, but it is unchecked, so <literal>negate (-2147483648::Int)</literal> is just
 209              <literal>-2147483648</literal>.  In short, one can write <literal>minBound::Int</literal> as
 210              a literal with the expected meaning (but that is not in general guaranteed.
 211              </para>
 212
 213           <para>The <literal>fromIntegral</literal> function also
 214           preserves bit-patterns when converting between the sized
 215           integral types (<literal>Int8</literal>,
 216           <literal>Int16</literal>, <literal>Int32</literal>,
 217           <literal>Int64</literal> and the unsigned
 218           <literal>Word</literal> variants), see the modules
 219           <literal>Data.Int</literal> and <literal>Data.Word</literal>
 220           in the library documentation.</para>
 221         </listitem>
 222       </varlistentry>
 223
 224       <varlistentry>
 225         <term>Unchecked float arithmetic</term>
 226         <listitem>
 227           <para>Operations on <literal>Float</literal> and
 228           <literal>Double</literal> numbers are
 229           <emphasis>unchecked</emphasis> for overflow, underflow, and
 230           other sad occurrences.  (note, however that some
 231           architectures trap floating-point overflow and
 232           loss-of-precision and report a floating-point exception,
 233           probably terminating the
 234           program)<indexterm><primary>floating-point
 235           exceptions</primary></indexterm>.</para>
 236         </listitem>
 237       </varlistentry>
 238     </variablelist>
 239
 240     </sect2>
 241   </sect1>
 242
 243
 244   <sect1 id="bugs">
 245     <title>Known bugs or infelicities</title>
 246
 247     <para>In addition to the divergences from the Haskell 98 standard
 248     listed above, GHC has the following known bugs or
 249     infelicities.</para>
 250
 251   <sect2 id="bugs-ghc">
 252     <title>Bugs in GHC</title>
 253
 254     <itemizedlist>
 255       <listitem>
 256         <para> GHC can warn about non-exhaustive or overlapping
 257         patterns (see <xref linkend="options-sanity">), and usually
 258         does so correctly.  But not always.  It gets confused by
 259         string patterns, and by guards, and can then emit bogus
 260         warnings.  The entire overlap-check code needs an overhaul
 261         really.</para>
 262       </listitem>
 263
 264       <listitem>
 265         <para>GHC does not allow you to have a data type with a context
 266            that mentions type variables that are not data type parameters.
 267           For example:
 268 <programlisting>
 269   data C a b => T a = MkT a
 270 </programlisting>
 271           so that <literal>MkT</literal>'s type is
 272 <programlisting>
 273   MkT :: forall a b. C a b => a -> T a
 274 </programlisting>
 275         In principle, with a suitable class declaration with a functional dependency,
 276          it's possible that this type is not ambiguous; but GHC nevertheless rejects
 277           it.  The type variables mentioned in the context of the data type declaration must
 278         be among the type parameters of the data type.</para>
 279       </listitem>
 280
 281       <listitem>
 282         <para>GHC's inliner can be persuaded into non-termination
 283         using the standard way to encode recursion via a data type:</para>
 284 <programlisting>
 285   data U = MkU (U -> Bool)
 286
 287   russel :: U -> Bool
 288   russel u@(MkU p) = not $ p u
 289
 290   x :: Bool
 291   x = russel (MkU russel)
 292 </programlisting>
 293
 294         <para>We have never found another class of programs, other
 295         than this contrived one, that makes GHC diverge, and fixing
 296         the problem would impose an extra overhead on every
 297         compilation.  So the bug remains un-fixed.  There is more
 298         background in <ulink
 299         url="http://research.microsoft.com/~simonpj/Papers/inlining">
 300         Secrets of the GHC inliner</ulink>.</para>
 301       </listitem>
 302     </itemizedlist>
 303   </sect2>
 304
 305   <sect2 id="bugs-ghci">
 306     <title>Bugs in GHCi (the interactive GHC)</title>
 307     <itemizedlist>
 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>On Windows, there's a GNU ld/BFD bug
 331       whereby it emits bogus PE object files that have more than
 332       0xffff relocations. When GHCi tries to load a package affected by this
 333       bug, you get an error message of the form
 334 <programlisting>
 335   Loading package javavm ... linking ... Overflown relocs: 4
 336 </programlisting>
 337       The last time we looked, this bug still
 338       wasn't fixed in the BFD codebase, and there wasn't any
 339       noticeable interest in fixing it when we reported the bug
 340       back in 2001 or so.
 341       </para>
 342       <para>The workaround is to split up the .o files that make up
 343       your package into two or more .o's, along the lines of
 344       how the "base" package does it.</para>
 345       </listitem>
 346     </itemizedlist>
 347   </sect2>
 348   </sect1>
 349
 350 </chapter>
 351
 352 <!-- Emacs stuff:
 353      ;;; Local Variables: ***
 354      ;;; mode: sgml ***
 355      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 356      ;;; End: ***
 357  -->