ghc/docs/users_guide/vs_haskell.sgml

   1 <Sect1 id="vs-Haskell-defn">
   2 <Title>Haskell&nbsp;98 vs.&nbsp;Glasgow Haskell: language non-compliance
   3 </Title>
   4
   5 <Para>
   6 <IndexTerm><Primary>GHC vs the Haskell 98 language</Primary></IndexTerm>
   7 <IndexTerm><Primary>Haskell 98 language vs GHC</Primary></IndexTerm>
   8 </Para>
   9
  10 <Para>
  11 This section lists Glasgow Haskell infelicities in its implementation
  12 of Haskell&nbsp;98.  See also the &ldquo;when things go wrong&rdquo; section
  13 (<XRef LinkEnd="wrong">)
  14 for information about crashes, space leaks, and other undesirable
  15 phenomena.
  16 </Para>
  17
  18 <Para>
  19 The limitations here are listed in Haskell-Report order (roughly).
  20 </Para>
  21
  22   <sect2 id="infelicities-lexical">
  23     <title>Lexical syntax</title>
  24
  25     <itemizedlist>
  26       <listitem>
  27         <para>The Haskell report specifies that programs may be
  28         written using Unicode.  GHC only accepts the ISO-8859-1
  29         character set at the moment.</para>
  30       </listitem>
  31
  32       <listitem>
  33         <para>Certain lexical rules regarding qualified identifiers
  34         are slightly different in GHC compared to the Haskell report.
  35         When you have
  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>
  40       </listitem>
  41     </itemizedlist>
  42   </sect2>
  43
  44   <sect2 id="infelicities-syntax">
  45     <title>Context-free syntax</title>
  46
  47     <itemizedlist>
  48       <listitem>
  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>
  54 <programlisting>
  55 infix 5 |-
  56 infix 9 :=
  57
  58 data Equal = Char := Int
  59
  60 0 |- x:=y = 1 |- x:=y      -- XXX fails here
  61 </programlisting>
  62       </listitem>
  63
  64       <listitem>
  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:
  68 <programlisting>
  69     let x = 42 in x == 42 == True
  70 </programlisting>
  71         and parses as:
  72 <programlisting>
  73     (let x = 42 in x == 42) == True
  74 </programlisting>
  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:
  82 <programlisting>
  83     (let x = 42 in x == 42 == True)
  84 </programlisting>
  85         The Haskell report is arguably wrong here, but nevertheless
  86         it's a difference between GHC & Haskell 98.</para>
  87       </listitem>
  88     </itemizedlist>
  89   </sect2>
  90
  91 <Sect2 id="infelicities-exprs-pats">
  92 <Title>Expressions and patterns
  93 </Title>
  94
  95 <Para>
  96 <VariableList>
  97
  98 <VarListEntry>
  99 <Term>Very long <Literal>String</Literal> constants:</Term>
 100 <ListItem>
 101 <Para>
 102 May not go through.  If you add a &ldquo;string gap&rdquo; every
 103 few thousand characters, then the strings can be as long
 104 as you like.
 105 </Para>
 106
 107 <Para>
 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">).
 110 </Para>
 111 </ListItem>
 112 </VarListEntry>
 113 <VarListEntry>
 114 <Term>Single quotes in module names:</Term>
 115 <ListItem>
 116 <Para>
 117 It might work, but it's just begging for trouble.
 118 </Para>
 119 </ListItem>
 120 </VarListEntry>
 121 </VariableList>
 122 </Para>
 123
 124 </Sect2>
 125
 126 <Sect2 id="infelicities-decls">
 127 <Title>Declarations and bindings
 128 </Title>
 129
 130 <Para>
 131 None known.
 132 </Para>
 133
 134 </Sect2>
 135
 136 <Sect2 id="infelicities-Modules">
 137 <Title>Module system and interface files
 138 </Title>
 139
 140 <Para>
 141 <VariableList>
 142
 143 <VarListEntry>
 144 <Term> Namespace pollution </Term>
 145 <ListItem>
 146 <Para>
 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.
 151 </Para>
 152 </ListItem>
 153 </VarListEntry>
 154 </VariableList>
 155 </Para>
 156
 157 </Sect2>
 158
 159 <Sect2 id="infelicities-numbers">
 160 <Title>Numbers, basic types, and built-in classes
 161 </Title>
 162
 163 <Para>
 164 <VariableList>
 165
 166 <VarListEntry>
 167 <Term>Unchecked arithmetic:</Term>
 168 <ListItem>
 169 <Para>
 170 Arguably <Emphasis>not</Emphasis> an infelicity, but&hellip; 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>.
 179 </Para>
 180
 181 <Para>
 182 Use <Literal>Integer</Literal>, <Literal>Rational</Literal>, etc.,
 183 numeric types if this stuff keeps you awake at night.
 184 </Para>
 185 </ListItem>
 186 </VarListEntry>
 187 <VarListEntry>
 188 <Term>Multiply-defined array elements&mdash;not checked:</Term>
 189 <ListItem>
 190 <Para>
 191 This code fragment <Emphasis>should</Emphasis> elicit a fatal error, but it does not:
 192
 193 <ProgramListing>
 194 main = print (array (1,1) [(1,2), (1,3)])
 195 </ProgramListing>
 196
 197 </Para>
 198 </ListItem>
 199 </VarListEntry>
 200 </VariableList>
 201 </Para>
 202
 203 </Sect2>
 204
 205 <Sect2 id="infelicities-Prelude">
 206 <Title>In Prelude support
 207 </Title>
 208
 209 <Para>
 210 <VariableList>
 211
 212         <varlistentry>
 213           <term>The <literal>Char</literal> type</term>
 214           <indexterm><primary><literal>Char</literal></primary><secondary>size
 215           of</secondary></indexterm>
 216           <listitem>
 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>
 222           </listitem>
 223         </varlistentry>
 224
 225 <VarListEntry>
 226 <Term>Arbitrary-sized tuples:</Term>
 227 <ListItem>
 228 <Para>
 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.
 234 </Para>
 235
 236 <Para>
 237 These limitations are easily subvertible, so please ask if you get
 238 stuck on them.
 239 </Para>
 240 </ListItem>
 241 </VarListEntry>
 242 </VariableList>
 243 </Para>
 244
 245 </Sect2>
 246
 247 </Sect1>
 248
 249 <!-- Emacs stuff:
 250      ;;; Local Variables: ***
 251      ;;; mode: sgml ***
 252      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 253      ;;; End: ***
 254  -->