-<Sect1 id="vs-Haskell-defn">
-<Title>Haskell 98 vs. Glasgow Haskell: language non-compliance
-</Title>
-
-<Para>
-<IndexTerm><Primary>GHC vs the Haskell 98 language</Primary></IndexTerm>
-<IndexTerm><Primary>Haskell 98 language vs GHC</Primary></IndexTerm>
-</Para>
-
-<Para>
-This section lists Glasgow Haskell infelicities in its implementation
-of Haskell 98. See also the ``when things go wrong'' section
-(<XRef LinkEnd="wrong">)
-for information about crashes, space leaks, and other undesirable
-phenomena.
-</Para>
-
-<Para>
-The limitations here are listed in Haskell-Report order (roughly).
-</Para>
-
-<Sect2 id="infelicities-exprs-pats">
-<Title>Expressions and patterns
-</Title>
-
-<Para>
-<VariableList>
-
-<VarListEntry>
-<Term>Very long <Literal>String</Literal> constants:</Term>
-<ListItem>
-<Para>
-May not go through. If you add a ``string gap'' every
-few thousand characters, then the strings can be as long
-as you like.
-</Para>
-
-<Para>
-Bear in mind that string gaps and the <Literal>-cpp</Literal><IndexTerm><Primary>-cpp option</Primary></IndexTerm>
-option don't mix very well (see <XRef LinkEnd="c-pre-processor">).
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
-<Term>Very long literal lists:</Term>
-<ListItem>
-<Para>
-These may tickle a ``yacc stack overflow'' error in the parser.
-(It depends on the Yacc used to build your parser.)
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
-<Term>Single quotes in module names:</Term>
-<ListItem>
-<Para>
-It might work, but it's just begging for trouble.
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-<Sect2 id="infelicities-decls">
-<Title>Declarations and bindings
-</Title>
-
-<Para>
-<VariableList>
-
-<VarListEntry>
-<Term>Derived instances for records:</Term>
-<ListItem>
-<Para>
-Hmmm.
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-<Sect2 id="infelicities-Modules">
-<Title>Module system and interface files
-</Title>
-
-<Para>
-<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 program, or you will be
-comprehensively screwed.
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-<Sect2 id="infelicities-numbers">
-<Title>Numbers, basic types, and built-in classes
-</Title>
-
-<Para>
-<VariableList>
-
-<VarListEntry>
-<Term>Unchecked arithmetic:</Term>
-<ListItem>
-<Para>
-Arguably <Emphasis>not</Emphasis> an infelicity, but… Bear in mind that
-operations on <Literal>Int</Literal>, <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)<IndexTerm><Primary>floating-point exceptions</Primary></IndexTerm>.
-</Para>
-
-<Para>
-Use <Literal>Integer</Literal>, <Literal>Rational</Literal>, etc., numeric types if this stuff
-keeps you awake at night.
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
-<Term>Multiply-defined array elements—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>
-
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-<Sect2 id="infelicities-Prelude">
-<Title>In Prelude support
-</Title>
-
-<Para>
-<VariableList>
-
-<VarListEntry>
-<Term>Arbitrary-sized tuples:</Term>
-<ListItem>
-<Para>
-Plain old tuples of arbitrary size <Emphasis>do</Emphasis> work.
-</Para>
-
-<Para>
-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>
-These limitations are easily subvertible, so please ask if you get
-stuck on them.
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
-<Term>Unicode character set:</Term>
-<ListItem>
-<Para>
-Haskell 98 embraces the Unicode character set, but GHC doesn't
-handle it. Yet.
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-</Sect1>
+<sect1 id="vs-Haskell-defn">
+ <title>Haskell 98 vs. 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>
+
+ <para>This section lists Glasgow Haskell infelicities in its
+ implementation of Haskell 98. See also the “when things
+ go wrong” section (<XRef LinkEnd="wrong">) for information
+ about crashes, space leaks, and other undesirable phenomena.</para>
+
+ <para>The limitations here are listed in Haskell Report order
+ (roughly).</para>
+
+ <sect2 id="haskell98-divergence">
+ <title>Divergence from Haskell 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>
+
+ <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>
+ </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:
+<programlisting>
+ let x = 42 in x == 42 == True</programlisting>
+ and parses as:
+<programlisting>
+ (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:
+<programlisting>
+ (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 “string
+ gap” 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
+ program, or you may be comprehensively screwed.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ </sect3>
+
+ <sect3 id="infelicities-numbers">
+ <title>Numbers, basic types, and built-in classes</title>
+
+ <variablelist>
+ <varlistentry>
+ <term>Multiply-defined array elements—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>
+
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ </sect3>
+
+ <sect3 id="infelicities-Prelude">
+ <title>In Prelude support</title>
+
+ <variablelist>
+ <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>
+
+ <varlistentry>
+ <term>Arbitrary-sized tuples:</term>
+ <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>
+ </variablelist>
+ </sect3>
+ </sect2>
+
+ <sect2 id="haskell98-undefined">
+ <title>GHC's interpretation of undefined behaviour in
+ Haskell 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>
+
+ <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
+ <literal>Word</literal> variants), see <xref
+ linkend="sec-Int"> and <xref linkend="sec-Word">.</para>
+
+ </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>
+
+<!-- Emacs stuff:
+ ;;; Local Variables: ***
+ ;;; mode: sgml ***
+ ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter" "sect1") ***
+ ;;; End: ***
+ -->
projects / ghc-hetmet.git / blobdiff