1 <Sect1 id="vs-Haskell-defn">
2 <Title>Haskell 98 vs. Glasgow Haskell: language non-compliance
6 <IndexTerm><Primary>GHC vs the Haskell 98 language</Primary></IndexTerm>
7 <IndexTerm><Primary>Haskell 98 language vs GHC</Primary></IndexTerm>
11 This section lists Glasgow Haskell infelicities in its implementation
12 of Haskell 98. See also the “when things go wrong” section
13 (<XRef LinkEnd="wrong">)
14 for information about crashes, space leaks, and other undesirable
19 The limitations here are listed in Haskell-Report order (roughly).
22 <sect2 id="infelicities-lexical">
23 <title>Lexical syntax</title>
27 <para>The Haskell report specifies that programs may be
28 written using Unicode. GHC only accepts the ISO-8879-1
29 character set at the moment.</para>
33 <para>Certain lexical rules regarding qualified identifiers
34 are slightly different in GHC compared to the Haskell report.
36 <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
37 such as <literal>M.\</literal>, GHC will interpret it as a
38 single qualified operator rather than the two lexemes
39 <literal>M</literal> and <literal>.\</literal>.</para>
44 <sect2 id="infelicities-syntax">
45 <title>Context-free syntax</title>
49 <para>GHC doesn't do fixity resolution on the left hand side
50 of a binding before deciding which symbol is the function
51 symbol. For example, the following fails, because GHC makes
52 the assumption that the function symbol is
53 <literal>|-</literal>:</para>
58 data Equal = Char := Int
60 0 |- x:=y = 1 |- x:=y -- XXX fails here
65 <para>GHC doesn't do fixity resolution in expressions during
66 parsing. For example, according to the Haskell report, the
67 following expression is legal Haskell:
69 let x = 42 in x == 42 == True
73 (let x = 42 in x == 42) == True
75 because according to the report, the <literal>let</literal>
76 expression <quote>extends as far to the right as
77 possible</quote>. Since it can't extend past the second
78 equals sign without causing a parse error
79 (<literal>==</literal> is non-fix), the
80 <literal>let</literal>-expression must terminate there. GHC
81 simply gobbles up the whole expression, parsing like this:
83 (let x = 42 in x == 42 == True)
85 The Haskell report is arguably wrong here, but nevertheless
86 it's a difference between GHC & Haskell 98.</para>
91 <Sect2 id="infelicities-exprs-pats">
92 <Title>Expressions and patterns
99 <Term>Very long <Literal>String</Literal> constants:</Term>
102 May not go through. If you add a “string gap” every
103 few thousand characters, then the strings can be as long
108 Bear in mind that string gaps and the <Option>-cpp</Option><IndexTerm><Primary>-cpp option</Primary></IndexTerm>
109 option don't mix very well (see <XRef LinkEnd="c-pre-processor">).
114 <Term>Single quotes in module names:</Term>
117 It might work, but it's just begging for trouble.
126 <Sect2 id="infelicities-decls">
127 <Title>Declarations and bindings
136 <Sect2 id="infelicities-Modules">
137 <Title>Module system and interface files
144 <Term> Namespace pollution </Term>
147 Several modules internal to GHC are visible in the standard namespace.
148 All of these modules begin with <Literal>Prel</Literal>, so the rule
149 is: don't use any modules beginning with <Literal>Prel</Literal> in
150 your program, or you will be comprehensively screwed.
159 <Sect2 id="infelicities-numbers">
160 <Title>Numbers, basic types, and built-in classes
167 <Term>Unchecked arithmetic:</Term>
170 Arguably <Emphasis>not</Emphasis> an infelicity, but… Bear in
171 mind that operations on <Literal>Int</Literal>,
172 <Literal>Float</Literal>, and <Literal>Double</Literal> numbers are
173 <Emphasis>unchecked</Emphasis> for overflow, underflow, and other sad
174 occurrences. (note, however that some architectures trap
175 floating-point overflow and loss-of-precision and report a
176 floating-point exception, probably terminating the
177 program)<IndexTerm><Primary>floating-point
178 exceptions</Primary></IndexTerm>.
182 Use <Literal>Integer</Literal>, <Literal>Rational</Literal>, etc.,
183 numeric types if this stuff keeps you awake at night.
188 <Term>Multiply-defined array elements—not checked:</Term>
191 This code fragment <Emphasis>should</Emphasis> elicit a fatal error, but it does not:
194 main = print (array (1,1) [(1,2), (1,3)])
205 <Sect2 id="infelicities-Prelude">
206 <Title>In Prelude support
213 <term>The <literal>Char</literal> type</term>
214 <indexterm><primary><literal>Char</literal></primary><secondary>size
215 of</secondary></indexterm>
217 <para>The Haskell report says that the
218 <literal>Char</literal> type holds 16 bits. GHC follows
219 the ISO-10646 standard a little more closely:
220 <literal>maxBound :: Char</literal> in GHC is
221 <literal>0x10FFFF</literal>.</para>
226 <Term>Arbitrary-sized tuples:</Term>
229 Tuples are currently limited to size 61. HOWEVER: standard instances
230 for tuples (<Literal>Eq</Literal>, <Literal>Ord</Literal>,
231 <Literal>Bounded</Literal>, <Literal>Ix</Literal>
232 <Literal>Read</Literal>, and <Literal>Show</Literal>) are available
233 <Emphasis>only</Emphasis> up to 5-tuples.
237 These limitations are easily subvertible, so please ask if you get
250 ;;; Local Variables: ***
252 ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***