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   <indexterm><primary>GHC vs the Haskell 98 language</primary></indexterm>
   6   <indexterm><primary>Haskell 98 language vs GHC</primary></indexterm>
   7
   8   <para>This section lists Glasgow Haskell infelicities in its
   9   implementation of Haskell&nbsp;98.  See also the &ldquo;when things
  10   go wrong&rdquo; section (<XRef LinkEnd="wrong">) for information
  11   about crashes, space leaks, and other undesirable phenomena.</para>
  12
  13   <para>The limitations here are listed in Haskell-Report order
  14   (roughly).</para>
  15
  16   <sect2 id="haskell98-divergence">
  17     <title>Divergence from Haskell&nbsp;98</title>
  18
  19
  20     <sect3 id="infelicities-lexical">
  21       <title>Lexical syntax</title>
  22
  23       <itemizedlist>
  24         <listitem>
  25           <para>The Haskell report specifies that programs may be
  26           written using Unicode.  GHC only accepts the ISO-8859-1
  27           character set at the moment.</para>
  28         </listitem>
  29
  30         <listitem>
  31           <para>Certain lexical rules regarding qualified identifiers
  32           are slightly different in GHC compared to the Haskell
  33           report.  When you have
  34           <replaceable>module</replaceable><literal>.</literal><replaceable>reservedop</replaceable>,
  35           such as <literal>M.\</literal>, GHC will interpret it as a
  36           single qualified operator rather than the two lexemes
  37           <literal>M</literal> and <literal>.\</literal>.</para>
  38         </listitem>
  39       </itemizedlist>
  40     </sect3>
  41
  42       <sect3 id="infelicities-syntax">
  43         <title>Context-free syntax</title>
  44
  45       <itemizedlist>
  46         <listitem>
  47           <para>GHC doesn't do fixity resolution in expressions during
  48           parsing.  For example, according to the Haskell report, the
  49           following expression is legal Haskell:
  50 <programlisting>
  51     let x = 42 in x == 42 == True</programlisting>
  52         and parses as:
  53 <programlisting>
  54     (let x = 42 in x == 42) == True</programlisting>
  55
  56           because according to the report, the <literal>let</literal>
  57           expression <quote>extends as far to the right as
  58           possible</quote>.  Since it can't extend past the second
  59           equals sign without causing a parse error
  60           (<literal>==</literal> is non-fix), the
  61           <literal>let</literal>-expression must terminate there.  GHC
  62           simply gobbles up the whole expression, parsing like this:
  63 <programlisting>
  64     (let x = 42 in x == 42 == True)</programlisting>
  65
  66           The Haskell report is arguably wrong here, but nevertheless
  67           it's a difference between GHC & Haskell 98.</para>
  68         </listitem>
  69       </itemizedlist>
  70     </sect3>
  71
  72   <sect3 id="infelicities-exprs-pats">
  73       <title>Expressions and patterns</title>
  74
  75       <variablelist>
  76         <varlistentry>
  77           <term>Very long <literal>String</literal> constants:</term>
  78           <listitem>
  79             <para>May not go through.  If you add a &ldquo;string
  80             gap&rdquo; every few thousand characters, then the strings
  81             can be as long as you like.</para>
  82
  83             <para>Bear in mind that string gaps and the
  84             <option>-cpp</option><indexterm><primary><option>-cpp</option>
  85             </primary></indexterm> option don't mix very well (see
  86             <xref linkend="c-pre-processor">).</para>
  87           </listitem>
  88         </varlistentry>
  89       </variablelist>
  90
  91     </sect3>
  92
  93     <sect3 id="infelicities-decls">
  94       <title>Declarations and bindings</title>
  95
  96       <para>None known.</para>
  97
  98     </sect3>
  99
 100     <sect3 id="infelicities-Modules">
 101       <title>Module system and interface files</title>
 102
 103       <variablelist>
 104
 105         <varlistentry>
 106           <term> Namespace pollution </term>
 107           <listitem>
 108             <para>Several modules internal to GHC are visible in the
 109             standard namespace.  All of these modules begin with
 110             <literal>Prel</literal>, so the rule is: don't use any
 111             modules beginning with <literal>Prel</literal> in your
 112             program, or you will be comprehensively screwed.</para>
 113           </listitem>
 114         </varlistentry>
 115       </variablelist>
 116
 117     </sect3>
 118
 119     <sect3 id="infelicities-numbers">
 120       <title>Numbers, basic types, and built-in classes</title>
 121
 122       <variablelist>
 123         <varlistentry>
 124           <term>Multiply-defined array elements&mdash;not checked:</term>
 125           <listitem>
 126             <para>This code fragment <emphasis>should</emphasis>
 127             elicit a fatal error, but it does not:
 128
 129 <programlisting>
 130 main = print (array (1,1) [(1,2), (1,3)])</programlisting>
 131
 132             </para>
 133           </listitem>
 134         </varlistentry>
 135       </variablelist>
 136
 137     </sect3>
 138
 139       <sect3 id="infelicities-Prelude">
 140         <title>In Prelude support</title>
 141
 142       <variablelist>
 143         <varlistentry>
 144           <term>The <literal>Char</literal> type</term>
 145           <indexterm><primary><literal>Char</literal></primary><secondary>size
 146           of</secondary></indexterm>
 147           <listitem>
 148             <para>The Haskell report says that the
 149             <literal>Char</literal> type holds 16 bits.  GHC follows
 150             the ISO-10646 standard a little more closely:
 151             <literal>maxBound :: Char</literal> in GHC is
 152             <literal>0x10FFFF</literal>.</para>
 153           </listitem>
 154         </varlistentry>
 155
 156         <varlistentry>
 157           <term>Arbitrary-sized tuples:</term>
 158           <listitem>
 159             <para>Tuples are currently limited to size 61.  HOWEVER:
 160             standard instances for tuples (<literal>Eq</literal>,
 161             <literal>Ord</literal>, <literal>Bounded</literal>,
 162             <literal>Ix</literal> <literal>Read</literal>, and
 163             <literal>Show</literal>) are available
 164             <emphasis>only</emphasis> up to 5-tuples.</para>
 165
 166             <para>This limitation is easily subvertible, so please ask
 167             if you get stuck on it.</para>
 168             </listitem>
 169           </varlistentry>
 170         </variablelist>
 171     </sect3>
 172   </sect2>
 173
 174   <sect2 id="haskell98-undefined">
 175     <title>GHC's interpretation of undefined behaviour in
 176     Haskell&nbsp;98</title>
 177
 178     <para>This section documents GHC's take on various issues that are
 179     left undefined or implementation specific in Haskell 98.</para>
 180
 181     <variablelist>
 182       <varlistentry>
 183         <term>Sized integral types</term>
 184         <indexterm><primary><literal>Int</literal></primary><secondary>size of</secondary>
 185         </indexterm>
 186
 187         <listitem>
 188           <para>In GHC the <literal>Int</literal> type follows the
 189           size of an address on the host architecture; in other words
 190           it holds 32 bits on a 32-bit machine, and 64-bits on a
 191           64-bit machine.</para>
 192
 193           <para>Arithmetic on <literal>Int</literal> is unchecked for
 194           overflow<indexterm><primary>overflow</primary><secondary><literal>Int</literal></secondary>
 195             </indexterm>, so all operations on <literal>Int</literal> happen
 196           modulo
 197           2<superscript><replaceable>n</replaceable></superscript>
 198           where <replaceable>n</replaceable> is the size in bits of
 199           the <literal>Int</literal> type.</para>
 200
 201           <para>The <literal>fromInteger</literal><indexterm><primary><literal>fromInteger</literal></primary>
 202             </indexterm>function (and hence
 203           also <literal>fromIntegral</literal><indexterm><primary><literal>fromIntegral</literal></primary>
 204             </indexterm>) is a special case when
 205           converting to <literal>Int</literal>.  The value of
 206           <literal>fromIntegral x :: Int</literal> is given by taking
 207           the lower <replaceable>n</replaceable> bits of <literal>(abs
 208           x)</literal>, multiplied by the sign of <literal>x</literal>
 209           (in 2's complement <replaceable>n</replaceable>-bit
 210           arithmetic).  This behaviour was chosen so that for example
 211           writing <literal>0xffffffff :: Int</literal> preserves the
 212           bit-pattern in the resulting <literal>Int</literal>.</para>
 213         </listitem>
 214       </varlistentry>
 215
 216       <varlistentry>
 217         <term>Unchecked float arithmetic</term>
 218         <listitem>
 219           <para>Operations on <literal>Float</literal> and
 220           <literal>Double</literal> numbers are
 221           <emphasis>unchecked</emphasis> for overflow, underflow, and
 222           other sad occurrences.  (note, however that some
 223           architectures trap floating-point overflow and
 224           loss-of-precision and report a floating-point exception,
 225           probably terminating the
 226           program)<indexterm><primary>floating-point
 227           exceptions</primary></indexterm>.</para>
 228         </listitem>
 229       </varlistentry>
 230     </variablelist>
 231
 232   </sect2>
 233
 234 </sect1>
 235
 236 <!-- Emacs stuff:
 237      ;;; Local Variables: ***
 238      ;;; mode: sgml ***
 239      ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
 240      ;;; End: ***
 241  -->