very often, and use the interpreter for the code being actively
developed.</para>
- <para>When loading up source files with <literal>:load</literal>,
- GHCi looks for any corresponding compiled object files, and will
- use one in preference to interpreting the source if possible. For
- example, suppose we have a 4-module program consisting of modules
- A, B, C, and D. Modules B and C both import D only,
- and A imports both B & C:</para>
+ <para>When loading up source modules with <literal>:load</literal>,
+ GHCi normally looks for any corresponding compiled object files,
+ and will use one in preference to interpreting the source if
+ possible. For example, suppose we have a 4-module program
+ consisting of modules A, B, C, and D. Modules B and C both import
+ D only, and A imports both B & C:</para>
<screen>
A
/ \
Ok, modules loaded: A, B, C, D.
</screen>
+ <para>The automatic loading of object files can sometimes lead to
+ confusion, because non-exported top-level definitions of a module
+ are only available for use in expressions at the prompt when the
+ module is interpreted (see <xref linkend="ghci-scope" />). For
+ this reason, you might sometimes want to force GHCi to load a
+ module using the interpreter. This can be done by prefixing
+ a <literal>*</literal> to the module name or filename when
+ using <literal>:load</literal>, for example</para>
+
+<screen>
+Prelude> :load *A
+Compiling A ( A.hs, interpreted )
+*A>
+</screen>
+
+<para>When the <literal>*</literal> is used, GHCi ignores any
+ pre-compiled object code and interprets the module. If you have
+ already loaded a number of modules as object code and decide that
+ you wanted to interpret one of them, instead of re-loading the whole
+ set you can use <literal>:add *M</literal> to specify that you want
+ <literal>M</literal> to be interpreted (note that this might cause
+ other modules to be interpreted too, because compiled modules cannot
+ depend on interpreted ones).</para>
+
+<para>To always compile everything to object code and never use the
+ interpreter, use the <literal>-fobject-code</literal> option (see
+ <xref linkend="ghci-obj" />).</para>
+
<para>HINT: since GHCi will only use a compiled object file if it
can be sure that the compiled version is up-to-date, a good technique
when working on a large program is to occasionally run
interpreter. As you modify code, the changed modules will be
interpreted, but the rest of the project will remain
compiled.</para>
-
</sect1>
<sect1 id="interactive-evaluation">
scopes from multiple modules, in any mixture of
<literal>*</literal> and non-<literal>*</literal> forms. GHCi
combines the scopes from all of these modules to form the scope
- that is in effect at the prompt. For technical reasons, GHCi
- can only support the <literal>*</literal>-form for modules which
- are interpreted, so compiled modules and package modules can
- only contribute their exports to the current scope.</para>
+ that is in effect at the prompt.</para>
+
+ <para>NOTE: for technical reasons, GHCi can only support the
+ <literal>*</literal>-form for modules that are interpreted.
+ Compiled modules and package modules can only contribute their
+ exports to the current scope. To ensure that GHCi loads the
+ interpreted version of a module, add the <literal>*</literal>
+ when loading the module, e.g. <literal>:load *M</literal>.</para>
<para>The scope is manipulated using the
<literal>:module</literal> command. For example, if the current
</para>
<sect3>
+ <title><literal>:module</literal> and
+ <literal>:load</literal></title>
+
+ <para>It might seem that <literal>:module</literal> and
+ <literal>:load</literal> do similar things: you can use both
+ to bring a module into scope. However, there is a clear
+ difference. GHCi is concerned with two sets of modules:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>The set of modules that are
+ currently <emphasis>loaded</emphasis>. This set is
+ modified
+ by <literal>:load</literal>, <literal>:add</literal>
+ and <literal>:reload</literal>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>The set of modules that are currently <emphasis>in
+ scope</emphasis> at the prompt. This set is modified
+ by <literal>:module</literal>, and it is also set
+ automatically
+ after <literal>:load</literal>, <literal>:add</literal>,
+ and <literal>:reload</literal>.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>You cannot add a module to the scope if it is not
+ loaded. This is why trying to
+ use <literal>:module</literal> to load a new module results
+ in the message “<literal>module M is not
+ loaded</literal>”.</para>
+ </sect3>
+
+ <sect3 id="ghci-import-qualified">
<title>Qualified names</title>
<para>To make life slightly easier, the GHCi prompt also
behaves as if there is an implicit <literal>import
qualified</literal> declaration for every module in every
- package, and every module currently loaded into GHCi.</para>
+ package, and every module currently loaded into GHCi. This
+ behaviour can be disabled with the flag <option>-fno-implicit-import-qualified</option><indexterm><primary><option>-fno-implicit-import-qualified</option></primary></indexterm>.</para>
</sect3>
<sect3>
<para>GHCi contains a simple imperative-style debugger in which you can
stop a running computation in order to examine the values of
variables. The debugger is integrated into GHCi, and is turned on by
- default: no flags are required to enable the debugging facilities. There
- is one major restriction: breakpoints and single-stepping are only
- available in <emphasis>interpreted</emphasis> modules; compiled code is
- invisible to the debugger.</para>
+ default: no flags are required to enable the debugging
+ facilities. There is one major restriction: breakpoints and
+ single-stepping are only available in interpreted modules;
+ compiled code is invisible to the debugger<footnote><para>Note that packages
+ only contain compiled code, so debugging a package requires
+ finding its source and loading that directly.</para></footnote>.</para>
<para>The debugger provides the following:
<itemizedlist>
</para>
<para>There is currently no support for obtaining a “stack
- trace”, but the tracing and history features provide a useful
- second-best, which will often be enough to establish the context of an
- error.</para>
+ trace”, but the tracing and history features provide a
+ useful second-best, which will often be enough to establish the
+ context of an error. For instance, it is possible to break
+ automatically when an exception is thrown, even if it is thrown
+ from within compiled code (see <xref
+ linkend="ghci-debugger-exceptions" />).</para>
<sect2 id="breakpoints">
<title>Breakpoints and inspecting variables</title>
<screen>
*Main> :set -fbreak-on-exception
*Main> :trace qsort ("abc" ++ undefined)
-"Stopped at <exception thrown>
+“Stopped at <exception thrown>
_exception :: e
[<exception thrown>] *Main> :hist
-1 : qsort.hs:3:24-38
<varlistentry>
<term>
- <literal>:add</literal> <replaceable>module</replaceable> ...
+ <literal>:add</literal> <optional><literal>*</literal></optional><replaceable>module</replaceable> ...
<indexterm><primary><literal>:add</literal></primary></indexterm>
</term>
<listitem>
<para>Add <replaceable>module</replaceable>(s) to the
current <firstterm>target set</firstterm>, and perform a
- reload.</para>
+ reload. Normally pre-compiled code for the module will be
+ loaded if available, or otherwise the module will be
+ compiled to byte-code. Using the <literal>*</literal>
+ prefix forces the module to be loaded as byte-code.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
- <literal>:load</literal> <replaceable>module</replaceable> ...
+ <literal>:load</literal> <optional><literal>*</literal></optional><replaceable>module</replaceable> ...
<indexterm><primary><literal>:load</literal></primary></indexterm>
</term>
<listitem>
to unload all the currently loaded modules and
bindings.</para>
+ <para>Normally pre-compiled code for a module will be loaded
+ if available, or otherwise the module will be compiled to
+ byte-code. Using the <literal>*</literal> prefix forces a
+ module to be loaded as byte-code.</para>
+
<para>After a <literal>:load</literal> command, the current
context is set to:</para>
Inside <replaceable>prompt</replaceable>, the sequence
<literal>%s</literal> is replaced by the names of the
modules currently in scope, and <literal>%%</literal> is
- replaced by <literal>%</literal>.</para>
+ replaced by <literal>%</literal>. If <replaceable>prompt</replaceable>
+ starts with " then it is parsed as a Haskell String;
+ otherwise it is treated as a literal string.</para>
</listitem>
</varlistentry>
flag is given, GHCi reads and executes commands from the following
files, in this order, if they exist:</para>
- <enumeratedlist>
+ <orderedlist>
<listitem>
<para><filename>./.ghci</filename></para>
</listitem>
<listitem>
<para><literal>$HOME/.ghci</literal></para>
</listitem>
- </enumeratedlist>
+ </orderedlist>
<para>The <filename>ghci.conf</filename> file is most useful for
turning on favourite options (eg. <literal>:set +s</literal>), and
<literal>:set</literal> like this. The changes won't take effect
until the next <literal>:load</literal>, though.)</para>
+ <para>Once you have a library of GHCi macros, you may want
+ to source them from separate files, or you may want to source
+ your <filename>.ghci</filename> file into your running GHCi
+ session while debugging it</para>
+
+<screen>
+:def source readFile
+</screen>
+
+ <para>With this macro defined in your <filename>.ghci</filename>
+ file, you can use <literal>:source file</literal> to read GHCi
+ commands from <literal>file</literal>. You can find (and contribute!-)
+ other suggestions for <filename>.ghci</filename> files on this Haskell
+ wiki page: <ulink
+ url="http://haskell.org/haskellwiki/GHC/GHCi">GHC/GHCi</ulink></para>
+
<para>Two command-line options control whether the
startup files files are read:</para>