1 %************************************************************************
3 \section[vs-Haskell-defn]{Haskell~1.3 vs.~Glasgow Haskell~2.02: language non-compliance}
4 \index{GHC vs the Haskell 1.4 language}
5 \index{Haskell 1.4 language vs GHC}
7 %************************************************************************
9 This section lists Glasgow Haskell infelicities in its implementation
10 of Haskell~1.4. See also the ``when things go wrong'' section
11 (\sectionref{wrong}) for information about crashes, space leaks, and
12 other undesirable phenomena.
14 GHC~2.02 does not have a ``Haskell~1.2 compatibility mode.'' If
15 enough people yelled loudly and long enough, it could conceivably
18 The limitations here are listed in Haskell-Report order (roughly).
19 %Limitations related to Glasgow extensions (unboxed numbers, etc.) are
20 %given thereafter (\sectionref{infelicities-Glasgow-exts}).
22 %************************************************************************
24 \subsection[infelicities-exprs-pats]{Expressions and patterns}
26 %************************************************************************
29 %-------------------------------------------------------------------
30 %\item[No @n+k@ patterns:]
31 %We took them out of GHC, because we thought they weren't going to
32 %survive into Haskell~1.3. But they did. And we haven't put them
35 %-------------------------------------------------------------------
36 \item[Very long @String@ constants:]
37 May not go through. If you add a ``string gap'' every
38 few thousand characters, then the strings can be as long
41 Bear in mind that string gaps and the \tr{-cpp}\index{-cpp option}
42 option don't mix. The C-preprocessor may munch the backslashes.
44 %-------------------------------------------------------------------
45 \item[Very long literal lists:]
46 These may tickle a ``yacc stack overflow'' error in the parser.
47 (It depends on the Yacc used to build your parser.)
49 %-------------------------------------------------------------------
50 \item[Single quotes in module names:]
51 It might work, but it's just begging for trouble.
54 %************************************************************************
56 \subsection[infelicities-decls]{Declarations and bindings}
58 %************************************************************************
61 %-------------------------------------------------------------------
62 \item[Derived instances of @Read@ and @Show@ for infix constructors:]
63 All the carry-on about derived @readsPrec@ and @showsPrec@ for infix
64 constructors---we don't do it (yet). We treat them the same way as
65 all other constructors.
67 %-------------------------------------------------------------------
68 \item[Derived instances for records:] Hmmm.
71 %************************************************************************
73 \subsection[infelicities-Modules]{Module system and interface files}
75 %************************************************************************
78 %-------------------------------------------------------------------
79 \item[Can't export primitives types (e.g., \tr{Int#}):]
84 %************************************************************************
86 \subsection[infelicities-numbers]{Numbers, basic types, and built-in classes}
88 %************************************************************************
91 %-------------------------------------------------------------------
92 \item[Very large/small fractional constants:]
93 (i.e., with a decimal point somewhere) GHC does not check that these
94 are out of range (e.g., for a @Float@), and bad things will inevitably
95 follow. (To be corrected?)
97 This problem does {\em not} exist for integral constants.
99 For very large/small fractional constants near the limits of your
100 floating-point precision, things may go wrong. (It's better than it
101 used to be.) Please report any such bugs.
103 %-------------------------------------------------------------------
104 \item[Unchecked arithmetic:]
105 Arguably {\em not} an infelicity, but... Bear in mind that operations
106 on \tr{Int}, \tr{Float}, and \tr{Double} numbers are {\em unchecked}
107 for overflow, underflow, and other sad occurrences.
109 Use \tr{Integer}, \tr{Rational}, etc., numeric types if this stuff
110 keeps you awake at night.
112 %-------------------------------------------------------------------
113 \item[Multiply-defined array elements---not checked:]
114 This code fragment {\em should} elicit a fatal error, but it does not:
116 main = print (array (1,1) [ 1:=2, 1:=3 ])
120 %************************************************************************
122 \subsection[infelicities-Prelude]{In Prelude support}
124 %************************************************************************
127 %-------------------------------------------------------------------
128 \item[Polymorphic @seq@:]
129 Required by the Haskell~1.3 prelude; not done yet. Consequently,
130 the @strict@ function doesn't really do what you want either.
132 %-------------------------------------------------------------------
133 \item[Arbitrary-sized tuples:]
134 Plain old tuples of arbitrary size {\em do} work. Note that lots of
135 overloading can give rise to large tuples ``under the hood'' of your
138 HOWEVER: standard instances for tuples (@Eq@, @Ord@, @Bounded@, @Ix@
139 @Read@, and @Show@) are available {\em only} up to 5-tuples.
141 These limitations are easily subvertible, so please ask if you get
144 %-------------------------------------------------------------------
145 \item[Unicode character set:]
146 Haskell~1.4 embraces the Unicode character set, but GHC~2.02 does
149 %-------------------------------------------------------------------
151 In Haskell~1.4, @Ord@ is dropped as a superclass of @Enum@. GHC~2.02
152 still has the @Ord@ constraint.