<literal>Show</literal></para>
</listitem>
</itemizedlist>
- The automatic printing of binding results can be supressed with
+ The automatic printing of binding results can be suppressed with
<option>:set -fno-print-bind-result</option> (this does not
- supress printing the result of non-binding statements).
+ suppress printing the result of non-binding statements).
<indexterm><primary><option>-fno-print-bind-result</option></primary></indexterm><indexterm><primary><option>-fprint-bind-result</option></primary></indexterm>.
You might want to do this to prevent the result of binding
statements from being fully evaluated by the act of printing
<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>
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
<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>
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>
<para>The command <literal>:step
<replaceable>expr</replaceable></literal> begins the evaluation of
<replaceable>expr</replaceable> in single-stepping mode. If
- <replaceable>expr</replaceable> is ommitted, then it single-steps from
+ <replaceable>expr</replaceable> is omitted, 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 (<=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
<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>
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.
<varlistentry>
<term>
- <literal>:browse</literal> <optional><literal>*</literal></optional><replaceable>module</replaceable> ...
+ <literal>:browse</literal> <optional><optional><literal>*</literal></optional><replaceable>module</replaceable></optional> ...
<indexterm><primary><literal>:browse</literal></primary></indexterm>
</term>
<listitem>
<para>Displays the identifiers defined by the module
<replaceable>module</replaceable>, which must be either
- loaded into GHCi or be a member of a package. If the
- <literal>*</literal> symbol is placed before the module
- name, then <emphasis>all</emphasis> the identifiers defined
- in <replaceable>module</replaceable> are shown; otherwise
- the list is limited to the exports of
+ loaded into GHCi or be a member of a package. If
+ <replaceable>module</replaceable> is omitted, the most
+ recently-loaded module is used.</para>
+
+ <para>If the <literal>*</literal> symbol is placed before
+ the module name, then <emphasis>all</emphasis> the
+ identifiers in scope in <replaceable>module</replaceable> are
+ shown; otherwise the list is limited to the exports of
<replaceable>module</replaceable>. The
<literal>*</literal>-form is only available for modules
which are interpreted; for compiled modules (including
<para>Generates a “tags” file for Vi-style editors
(<literal>:ctags</literal>) or
Emacs-style editors (<literal>:etags</literal>). If
- no filename is specified, the defaulit <filename>tags</filename> or
+ no filename is specified, the default <filename>tags</filename> or
<filename>TAGS</filename> is
used, respectively. Tags for all the functions, constructors and
types in the currently loaded modules are created. All modules must
projects / ghc-hetmet.git / blobdiff