Documentation for -fno-code and -fwrite-iface.

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

diff --git a/ghc/docs/users_guide/bugs.xml b/ghc/docs/users_guide/bugs.xml
index 76ab87d..ab0b9be 100644 (file)
--- a/ghc/docs/users_guide/bugs.xml
+++ b/ghc/docs/users_guide/bugs.xml
@@ -46,7 +46,27 @@
       <sect3 id="infelicities-syntax">
        <title>Context-free syntax</title>
        
-      <itemizedlist>
+       <itemizedlist>
+         <listitem>
+           <para>GHC is a little less strict about the layout rule when used
+             in <literal>do</literal> expressions.  Specifically, the
+             restriction that "a nested context must be indented further to
+             the right than the enclosing context" is relaxed to allow the
+             nested context to be at the same level as the enclosing context,
+             if the enclosing context is a <literal>do</literal>
+             expression.</para>
+
+           <para>For example, the following code is accepted by GHC:
+
+<programlisting>
+main = do args &lt;- getArgs
+         if null args then return [] else do
+          ps &lt;- mapM process args
+          mapM print ps</programlisting>
+
+             </para>
+         </listitem>
+
        <listitem>
          <para>GHC doesn't do fixity resolution in expressions during
          parsing.  For example, according to the Haskell report, the
@@ -103,7 +123,7 @@
 
 <programlisting>
 main = print (array (1,1) [(1,2), (1,3)])</programlisting>
-GHC's implemetation of <literal>array</literal> takes the value of an
+GHC's implementation of <literal>array</literal> takes the value of an
 array slot from the last (index,value) pair in the list, and does no
 checking for duplicates.  The reason for this is efficiency, pure and simple.
             </para>
@@ -145,6 +165,21 @@ checking for duplicates.  The reason for this is efficiency, pure and simple.
                octal escapes, so it seems inconsistent not to do so for integers too.</para>
            </listitem>
          </varlistentry>
+
+         <varlistentry>
+           <term><literal>isAlpha</literal></term>
+           <listitem>
+             <para>The Haskell 98 definition of <literal>isAlpha</literal>
+              is:</para>
+
+<programlisting>isAlpha c = isUpper c || isLower c</programlisting>
+
+             <para>GHC's implementation diverges from the Haskell 98
+              definition in the sense that Unicode alphabetic characters which
+              are neither upper nor lower case will still be identified as
+              alphabetic by <literal>isAlpha</literal>.</para>
+           </listitem>
+         </varlistentry>
        </variablelist>
     </sect3>
   </sect2>
@@ -248,9 +283,11 @@ checking for duplicates.  The reason for this is efficiency, pure and simple.
   <sect1 id="bugs">
     <title>Known bugs or infelicities</title>
 
-    <para>In addition to the divergences from the Haskell 98 standard
-    listed above, GHC has the following known bugs or
-    infelicities.</para>
+    <para>The bug tracker lists bugs that have been reported in GHC but not
+      yet fixed: see the <ulink url="http://sourceforge.net/projects/ghc/">SourceForge GHC
+    page</ulink>.  In addition to those, GHC also has the following known bugs
+      or  infelicities.  These bugs are more permanent; it is unlikely that
+      any of them will be fixed in the short term.</para>
 
   <sect2 id="bugs-ghc">
     <title>Bugs in GHC</title>
@@ -303,6 +340,17 @@ checking for duplicates.  The reason for this is efficiency, pure and simple.
         url="http://research.microsoft.com/~simonpj/Papers/inlining">
         Secrets of the GHC inliner</ulink>.</para>
       </listitem>
+
+      <listitem>
+       <para>GHC does not keep careful track of
+           what instance declarations are 'in scope' if they come from other packages.
+        Instead, all instance declarations that GHC has seen in other
+        packages are all in scope everywhere, whether or not the
+        module from that package is used by the command-line
+        expression.  This bug affects only the <option>--make</option> mode and
+         GHCi.</para>
+      </listitem>
+
     </itemizedlist>
   </sect2>
 
@@ -321,15 +369,6 @@ checking for duplicates.  The reason for this is efficiency, pure and simple.
         module (whatever that is).</para>
       </listitem>
 
-      <listitem>
-       <para>GHCi does not keep careful track of what instance
-        declarations are 'in scope' if they come from other packages.
-        Instead, all instance declarations that GHC has seen in other
-        packages are all in scope everywhere, whether or not the
-        module from that package is used by the command-line
-        expression.</para>
-      </listitem>
-
       <listitem> 
       <para>On Windows, there's a GNU ld/BFD bug
       whereby it emits bogus PE object files that have more than
@@ -356,6 +395,6 @@ Loading package javavm ... linking ... WARNING: Overflown relocation field (# re
 <!-- Emacs stuff:
      ;;; Local Variables: ***
      ;;; mode: xml ***
-     ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter" "sect1") ***
+     ;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
      ;;; End: ***
  -->