[project @ 2003-04-09 08:44:37 by simonpj]

[ghc-hetmet.git] / ghc / docs / users_guide / bugs.sgml

diff --git a/ghc/docs/users_guide/bugs.sgml b/ghc/docs/users_guide/bugs.sgml
index 47e203f..834e630 100644 (file)
--- a/ghc/docs/users_guide/bugs.sgml
+++ b/ghc/docs/users_guide/bugs.sgml
@@ -168,7 +168,7 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
        </varlistentry>
 
        <varlistentry>
-         <term>Arbitrary-sized tuples:</term>
+         <term>Arbitrary-sized tuples</term>
          <listitem>
            <para>Tuples are currently limited to size 61.  HOWEVER:
             standard instances for tuples (<literal>Eq</literal>,
@@ -181,6 +181,20 @@ main = print (array (1,1) [(1,2), (1,3)])</programlisting>
             if you get stuck on it.</para>
            </listitem>
          </varlistentry>
+
+         <varlistentry>
+           <term><literal>Read</literal>ing integers</term>
+           <listitem>
+             <para>GHC's implementation of the
+             <literal>Read</literal> class for integral types accepts
+             hexadeciaml and octal literals (the code in the Haskell
+             98 report doesn't).  So, for example,
+<programlisting>read "0xf00" :: Int</programlisting>
+              works in GHC.</para>
+             <para>A possible reason for this is that <literal>readLitChar</literal> accepts hex and
+               octal escapes, so it seems inconsistent not to do so for integers too.</para>
+           </listitem>
+         </varlistentry>
        </variablelist>
     </sect3>
   </sect2>
@@ -335,7 +349,7 @@ recursion via a data type:
   x :: Bool
   x = russel (MkU russel)
 </programlisting>
-We have never found another program, other than this contrived one, that makes GHC
+We have never found another class of programs, other than this contrived one, that makes GHC
 diverge, and fixing the problem would impose an extra overhead on every compilation.  So the
 bug remains un-fixed.  There is more background in
 <ulink