-<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>
-These limitations are easily subvertible, so please ask if you get
-stuck on them.
-</Para>
-</ListItem>
-</VarListEntry>
-</VariableList>
-</Para>
-
-</Sect2>
-
-</Sect1>
+ <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>
+ </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>