Update documentation for win32 DLL linking
[ghc-hetmet.git] / docs / users_guide / ghci.xml
index 82ee330..579cf23 100644 (file)
@@ -929,6 +929,7 @@ right :: [a]
         <literal>left</literal>:</para>
 
 <screen>
+[qsort.hs:2:15-46] *Main> :set -fprint-evld-with-show
 [qsort.hs:2:15-46] *Main> :print left
 left = (_t1::[a])
 </screen>
@@ -948,6 +949,13 @@ left = (_t1::[a])
         underscore, in this case
         <literal>_t1</literal>.</para>
 
+      <para>The flag <literal>-fprint-evld-with-show</literal> instructs
+      <literal>:print</literal> to reuse
+      available <literal>Show</literal> instances when possible. This happens
+      only when the contents of the variable being inspected 
+      are completely evaluated.</para>
+
+
       <para>If we aren't concerned about preserving the evaluatedness of a
         variable, we can use <literal>:force</literal> instead of
         <literal>:print</literal>.  The <literal>:force</literal> command
@@ -1017,6 +1025,7 @@ right :: [a]
       <para>The execution continued at the point it previously stopped, and has
         now stopped at the breakpoint for a second time.</para>
 
+
       <sect3 id="setting-breakpoints">
         <title>Setting breakpoints</title>
 
@@ -1109,8 +1118,10 @@ right :: [a]
         bug. GHCi offers two variants of stepping. Use 
        <literal>:step</literal>  to enable all the
         breakpoints in the program, and execute until the next breakpoint is
-        reached. Use <literal>:stepover</literal> to step over function
-       applications, which of course are executed all the same. 
+        reached. Use <literal>:steplocal</literal> to limit the set
+       of enabled breakpoints to those in the current top level function.
+       Similarly, use <literal>:stepmodule</literal> to single step only on
+       breakpoints contained in the current module.
        For example:</para>
 
 <screen>
@@ -1125,48 +1136,9 @@ _result :: IO ()
         <replaceable>expr</replaceable> is ommitted, then it single-steps from
         the current breakpoint. <literal>:stepover</literal> 
         works similarly.</para>
-      <para>In the current version of the debugger, <literal>:stepover</literal>
-       is limited to work locally in the lexical sense, that is in the context
-       of the current expression body.
-       When you run to the end of the expression, <literal>:stepover</literal>
-       stops working and switches to behave like regular <literal>:step</literal>. 
-       This means 
-       that it will fail to step over the last function application. As a result,
-       currently <literal>:stepover</literal> works great for monadic code, but 
-       interacts less perfectly with pure code. For example, if stopped at the 
-       line 2, on the entire expression 
-       <literal>qsort left ++ [a] ++ qsort right</literal>:</para>
-<screen>
-... [qsort2.hs:2:15-46] *Main> :step
-Stopped at qsort2.hs:2:15-46
-
-... [qsort2.hs:2:15-46] *Main> :list
-2  qsort (a:as) = qsort left ++ [a] ++ qsort right
-</screen>
-       
-      <para> The first <literal>:stepover</literal> will step over the first
-           <literal>qsort</literal> recursive call, as expected. The second one 
-           will step over the evaluation of <literal>[a]</literal>, again as
-           expected. However, the third one has lexically <quote>run out</quote>
-           of the current expression, and will behave like regular 
-           <literal>:step</literal>, performing one step of lazy evaluation and
-           stopping at the next breakpoint. In this case it is indeed the second
-           recursive application of <literal>qsort</literal>.</para>
-<screen>
-[qsort2.hs:2:36-46] *Main> :stepover
-Warning: no more breakpoints in this function body, switching to :step
-Stopped at qsort2.hs:(1,0)-(3,55)
-
-[qsort2.hs:2:36-46] *Main> :list
-_result :: [a]
-1  qsort [] = []
-2  qsort (a:as) = qsort left ++ [a] ++ qsort right
-3    where (left,right) = (filter (&lt;=a) as, filter (>a) as)
-</screen>
+
       <para>The <literal>:list</literal> command is particularly useful when
-        single-stepping, to see where you currently are, as just shown
-       in the above example.</para>
+        single-stepping, to see where you currently are:</para>
 
 <screen>
 [qsort.hs:5:7-47] *Main> :list
@@ -1372,9 +1344,13 @@ a :: a
         <literal>:trace</literal> and <literal>:history</literal> to establish
         the context.  However, <literal>head</literal> is in a library and
         we can't set a breakpoint on it directly.  For this reason, GHCi
-        provides the flag <literal>-fbreak-on-exception</literal> which causes
-        the evaluator to stop when an exception is thrown, just as it does when
-        a breakpoint is hit.  This is only really useful in conjunction with
+        provides the flags <literal>-fbreak-on-exception</literal> which causes
+        the evaluator to stop when an exception is thrown, and <literal>
+       -fbreak-on-error</literal>, which works similarly but stops only on 
+       uncaught exceptions. When stopping at an exception, GHCi will act 
+       just as it does when a breakpoint is hit, with the deviation that it
+       will not show you any source code location. Due to this, these 
+       commands are only really useful in conjunction with
         <literal>:trace</literal>, in order to log the steps leading up to the
         exception.  For example:</para>
 
@@ -1528,10 +1504,6 @@ Just 20
             CAF (e.g. main), stop at a breakpoint, and ask for the value of the
             CAF at the prompt again.</para>
         </listitem>
-       <listitem> <literal>:stepover</literal> only works lexically locally, in the
-         body of the current expression. As a result, it can be rather impredictable
-         when used in pure functional code, as opposed to monadic code.
-       </listitem>
        <listitem><para>
          Implicit parameters (see <xref linkend="implicit-parameters"/>) are only available 
          at the scope of a breakpoint if there is an explicit type signature.