bugs.sgml 13.4 KB
Newer Older
1
2
3
4
<Chapter id="bugs-and-infelicities">
  <title>Known bugs and infelicities
</title>

5
6
7
8
9
10
<sect1 id="vs-Haskell-defn">
  <title>Haskell&nbsp;98 vs.&nbsp;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>
11

12
13
14
15
  <para>This section lists Glasgow Haskell infelicities in its
  implementation of Haskell&nbsp;98.  See also the &ldquo;when things
  go wrong&rdquo; section (<XRef LinkEnd="wrong">) for information
  about crashes, space leaks, and other undesirable phenomena.</para>
16

rrt's avatar
rrt committed
17
  <para>The limitations here are listed in Haskell Report order
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
  (roughly).</para>

  <sect2 id="haskell98-divergence">
    <title>Divergence from Haskell&nbsp;98</title>
    
      
    <sect3 id="infelicities-lexical">
      <title>Lexical syntax</title>
      
      <itemizedlist>
	<listitem>
	  <para>The Haskell report specifies that programs may be
	  written using Unicode.  GHC only accepts the ISO-8859-1
	  character set at the moment.</para>
	</listitem>

	<listitem>
	  <para>Certain lexical rules regarding qualified identifiers
	  are slightly different in GHC compared to the Haskell
	  report.  When you have
	  <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
	  such as <literal>M.\</literal>, GHC will interpret it as a
	  single qualified operator rather than the two lexemes
	  <literal>M</literal> and <literal>.\</literal>.</para>
	</listitem>
43
44
45
46
47
48
49
50
51
52

	<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>
53
54
55
56
57
58
59
60
61
62
63
      </itemizedlist>
    </sect3>
      
      <sect3 id="infelicities-syntax">
	<title>Context-free syntax</title>
	
      <itemizedlist>
	<listitem>
	  <para>GHC doesn't do fixity resolution in expressions during
	  parsing.  For example, according to the Haskell report, the
	  following expression is legal Haskell:
64
<programlisting>
65
    let x = 42 in x == 42 == True</programlisting>
66
67
	and parses as:
<programlisting>
68
69
70
71
72
73
74
75
76
    (let x = 42 in x == 42) == True</programlisting>

          because according to the report, the <literal>let</literal>
	  expression <quote>extends as far to the right as
	  possible</quote>.  Since it can't extend past the second
	  equals sign without causing a parse error
	  (<literal>==</literal> is non-fix), the
	  <literal>let</literal>-expression must terminate there.  GHC
	  simply gobbles up the whole expression, parsing like this:
77
<programlisting>
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
    (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>
	</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 &ldquo;string
            gap&rdquo; 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>

    </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
rrt's avatar
rrt committed
126
            program, or you may be comprehensively screwed.</para>
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
	  </listitem>
	</varlistentry>
      </variablelist>

    </sect3>

    <sect3 id="infelicities-numbers">
      <title>Numbers, basic types, and built-in classes</title>

      <variablelist>
	<varlistentry>
	  <term>Multiply-defined array elements&mdash;not checked:</term>
	  <listitem>
	    <para>This code fragment <emphasis>should</emphasis>
	    elicit a fatal error, but it does not:

<programlisting>
main = print (array (1,1) [(1,2), (1,3)])</programlisting>
145

146
147
148
149
150
151
            </para>
	  </listitem>
	</varlistentry>
      </variablelist>
      
    </sect3>
rrt's avatar
rrt committed
152

153
154
155
156
      <sect3 id="infelicities-Prelude">
	<title>In Prelude support</title>

      <variablelist>
157
158
159
160
161
162
163
164
165
166
167
168
169
	<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>

170
	<varlistentry>
171
	  <term>Arbitrary-sized tuples</term>
172
173
174
175
176
177
178
179
180
181
182
183
	  <listitem>
	    <para>Tuples are currently limited to size 61.  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>

	    <para>This limitation is easily subvertible, so please ask
            if you get stuck on it.</para>
	    </listitem>
	  </varlistentry>
184
185
186
187
188
189
190
191
192
193

	  <varlistentry>
	    <term><literal>Read</literal>ing integers</term>
	    <listitem>
	      <para>GHC's implementation of the
	      <literal>Read</literal> class for integral types accepts
	      hexadeciaml and octal literals (the code in the Haskell
	      98 report doesn't).  So, for example,
<programlisting>read "0xf00" :: Int</programlisting>
              works in GHC.</para>
194
195
	      <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>
196
197
	    </listitem>
	  </varlistentry>
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
	</variablelist>
    </sect3>
  </sect2>

  <sect2 id="haskell98-undefined">
    <title>GHC's interpretation of undefined behaviour in
    Haskell&nbsp;98</title>

    <para>This section documents GHC's take on various issues that are
    left undefined or implementation specific in Haskell 98.</para>

    <variablelist>
      <varlistentry>
	<term>Sized integral types</term>
	<indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
	</indexterm>
	
	<listitem>
	  <para>In GHC the <literal>Int</literal> type follows the
	  size of an address on the host architecture; in other words
	  it holds 32 bits on a 32-bit machine, and 64-bits on a
	  64-bit machine.</para>

	  <para>Arithmetic on <literal>Int</literal> is unchecked for
	  overflow<indexterm><primary>overflow</primary><secondary><literal>Int</literal></secondary>
	    </indexterm>, so all operations on <literal>Int</literal> happen
	  modulo
	  2<superscript><replaceable>n</replaceable></superscript>
	  where <replaceable>n</replaceable> is the size in bits of
	  the <literal>Int</literal> type.</para>

	  <para>The <literal>fromInteger</literal><indexterm><primary><literal>fromInteger</literal></primary>
	    </indexterm>function (and hence
	  also <literal>fromIntegral</literal><indexterm><primary><literal>fromIntegral</literal></primary>
	    </indexterm>) is a special case when
	  converting to <literal>Int</literal>.  The value of
	  <literal>fromIntegral x :: Int</literal> is given by taking
	  the lower <replaceable>n</replaceable> bits of <literal>(abs
	  x)</literal>, multiplied by the sign of <literal>x</literal>
	  (in 2's complement <replaceable>n</replaceable>-bit
	  arithmetic).  This behaviour was chosen so that for example
	  writing <literal>0xffffffff :: Int</literal> preserves the
	  bit-pattern in the resulting <literal>Int</literal>.</para>
241

242
243
244
245
246
247
248
249
250
251
252
253
254

	   <para>Negative literals, such as <literal>-3</literal>, are
             specified by (a careful reading of) the Haskell Report as 
             meaning <literal>Prelude.negate (Prelude.fromInteger 3)</literal>.
	     So <literal>-2147483648</literal> means <literal>negate (fromInteger 2147483648)</literal>.
	     Since <literal>fromInteger</literal> takes the lower 32 bits of the representation,
	     <literal>fromInteger (2147483648::Integer)</literal>, computed at type <literal>Int</literal> is
	     <literal>-2147483648::Int</literal>.  The <literal>negate</literal> operation then
	     overflows, but it is unchecked, so <literal>negate (-2147483648::Int)</literal> is just
	     <literal>-2147483648</literal>.  In short, one can write <literal>minBound::Int</literal> as
	     a literal with the expected meaning (but that is not in general guaranteed.
             </para>

255
256
257
258
259
	  <para>The <literal>fromIntegral</literal> function also
	  preserves bit-patterns when converting between the sized
	  integral types (<literal>Int8</literal>,
	  <literal>Int16</literal>, <literal>Int32</literal>,
	  <literal>Int64</literal> and the unsigned
260
261
262
	  <literal>Word</literal> variants), see the modules
	  <literal>Data.Int</literal> and <literal>Data.Word</literal>
	  in the library documentation.</para>
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
	</listitem>
      </varlistentry>

      <varlistentry>
	<term>Unchecked float arithmetic</term>
	<listitem>
	  <para>Operations on <literal>Float</literal> and
          <literal>Double</literal> numbers are
          <emphasis>unchecked</emphasis> for overflow, underflow, and
          other sad occurrences.  (note, however that some
          architectures trap floating-point overflow and
          loss-of-precision and report a floating-point exception,
          probably terminating the
          program)<indexterm><primary>floating-point
          exceptions</primary></indexterm>.</para>
	</listitem>
      </varlistentry>
    </variablelist>
      
  </sect2>

</sect1>
285

286
287

<sect1 id="bugs">
288
  <title>Known bugs or infelicities</title>
289

290
<para>GHC has the following known bugs or infelicities:
291
292
<itemizedlist>

293
294
295
296
297
298
299
300
301
302
303
304
305
<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>



306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
<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>

340
341
342
343
344
345
346
347
348
349
350
351
<listitem><para>
GHC's inliner can be persuaded into non-termination using the standard way to encode
recursion via a data type:
<programlisting>
  data U = MkU (U -> Bool)
       
  russel :: U -> Bool
  russel u@(MkU p) = not $ p u
  
  x :: Bool
  x = russel (MkU russel)
</programlisting>
352
We have never found another class of programs, other than this contrived one, that makes GHC
353
354
355
356
357
358
359
360
361
362
363
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>

364
365
366
367
368
369
<!-- Emacs stuff:
     ;;; Local Variables: ***
     ;;; mode: sgml ***
     ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
     ;;; End: ***
 -->