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, if you ask GHCi to load a filename rather than a
+ module name (e.g. <literal>:load Main.hs</literal> rather than
+ <literal>:load Main</literal>) then any existing object file will
+ be ignored and the module will be interpreted rather than
+ compiled. Using <literal>-fobject-code</literal> disables this
+ behaviour (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">
<literal>IO</literal> monad.
<screen>
Prelude> x <- return 42
-42
Prelude> print x
42
Prelude>
<literal>x</literal> in future statements, for example to print
it as we did above.</para>
- <para>GHCi will print the result of a statement if and only if:
+ <para>If <option>-fprint-bind-result</option> is set then
+ GHCi will print the result of a statement if and only if:
<itemizedlist>
<listitem>
<para>The statement is not a binding, or it is a monadic binding
<literal>Show</literal></para>
</listitem>
</itemizedlist>
- The automatic printing of binding results can be supressed with
- <option>:set -fno-print-bind-result</option> (this does not
- supress 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
- them, for example.</para>
+ <indexterm><primary><option>-fprint-bind-result</option></primary></indexterm><indexterm><primary><option>-fno-print-bind-result</option></primary></indexterm>.
+ </para>
<para>Of course, you can also bind normal non-IO expressions
using the <literal>let</literal>-statement:</para>
<para>Note that <literal>let</literal> bindings do not automatically
print the value bound, unlike monadic bindings.</para>
+ <para>Hint: you can also use <literal>let</literal>-statements
+ to define functions at the prompt:</para>
+<screen>
+Prelude> let add a b = a + b
+Prelude> add 1 2
+3
+Prelude>
+</screen>
+ <para>However, this quickly gets tedious when defining functions
+ with multiple clauses, or groups of mutually recursive functions,
+ because the complete definition has to be given on a single line,
+ using explicit braces and semicolons instead of layout:</para>
+<screen>
+Prelude> let { f op n [] = n ; f op n (h:t) = h `op` f op n t }
+Prelude> f (+) 0 [1..3]
+6
+Prelude>
+</screen>
+ <para>To alleviate this issue, GHCi commands can be split over
+ multiple lines, by wrapping them in <literal>:{</literal> and
+ <literal>:}</literal> (each on a single line of its own):</para>
+<screen>
+Prelude> :{
+Prelude| let { g op n [] = n
+Prelude| ; g op n (h:t) = h `op` g op n t
+Prelude| }
+Prelude| :}
+Prelude> g (*) 1 [1..3]
+6
+</screen>
+ <para>Such multiline commands can be used with any GHCi command,
+ and the lines between <literal>:{</literal> and
+ <literal>:}</literal> are simply merged into a single line for
+ interpretation. That implies that each such group must form a single
+ valid command when merged, and that no layout rule is used.
+ The main purpose of multiline commands is not to replace module
+ loading but to make definitions in .ghci-files (see <xref
+ linkend="ghci-dot-files"/>) more readable and maintainable.</para>
+
<para>Any exceptions raised during the evaluation or execution
of the statement are caught and printed by the GHCi command line
interface (for more information on exceptions, see the module
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. This is why GHCi will always
+ interpret, not compile, a module if you specify its filename
+ rather than its module name to <literal>:load</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>
- <title>The <literal>:main</literal> command</title>
+ <title>The <literal>:main</literal> and <literal>:run</literal> commands</title>
<para>
When a program is compiled and executed, it can use the
["foo","bar"]
</screen>
+ <para>
+ We can also quote arguments which contains characters like
+ spaces, and they are treated like Haskell strings, or we can
+ just use Haskell list syntax:
+ </para>
+
+<screen>
+Prelude> :main foo "bar baz"
+["foo","bar baz"]
+Prelude> :main ["foo", "bar baz"]
+["foo","bar baz"]
+</screen>
+
+ <para>
+ Finally, other functions can be called, either with the
+ <literal>-main-is</literal> flag or the <literal>:run</literal>
+ command:
+ </para>
+
+<screen>
+Prelude> let foo = putStrLn "foo" >> System.Environment.getArgs >>= print
+Prelude> let bar = putStrLn "bar" >> System.Environment.getArgs >>= print
+Prelude> :set -main-is foo
+Prelude> :main foo "bar baz"
+foo
+["foo","bar baz"]
+Prelude> :run bar ["foo", "bar baz"]
+bar
+["foo","bar baz"]
+</screen>
+
</sect3>
</sect2>
<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>
<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-breakpoings">
+
+ <sect3 id="setting-breakpoints">
<title>Setting breakpoints</title>
<para>Breakpoints can be set in various ways. Perhaps the easiest way to
<para>Single-stepping is a great way to visualise the execution of your
program, and it is also a useful tool for identifying the source of a
- bug. The concept is simple: single-stepping enables all the
- breakpoints in the program and executes until the next breakpoint is
- reached, at which point you can single-step again, or continue
- normally. For example:</para>
+ 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>: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>
*Main> :step main
</screen>
<para>The command <literal>:step
- <replaceable>expr</replaceable></literal> begins the evaluation of
+ <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
- the current breakpoint.</para>
+ <replaceable>expr</replaceable> is omitted, then it single-steps from
+ the current breakpoint. <literal>:stepover</literal>
+ works similarly.</para>
<para>The <literal>:list</literal> command is particularly useful when
single-stepping, to see where you currently are:</para>
<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>
<programlisting>
import Prelude hiding (map)
-map :: (a->b) -> a -> b
+map :: (a->b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs
</programlisting>
<varlistentry>
<term>
- <literal>:browse</literal> <optional><literal>*</literal></optional><replaceable>module</replaceable> ...
+ <literal>:browse</literal><optional><literal>!</literal></optional> <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
modules from packages) only the non-<literal>*</literal>
- form of <literal>:browse</literal> is available.</para>
+ form of <literal>:browse</literal> is available.
+ If the <literal>!</literal> symbol is appended to the
+ command, data constructors and class methods will be
+ listed individually, otherwise, they will only be listed
+ in the context of their data type or class declaration.
+ The <literal>!</literal>-form also annotates the listing
+ with comments giving possible imports for each group of
+ entries.</para>
+<screen>
+Prelude> :browse! Data.Maybe
+-- not currently imported
+Data.Maybe.catMaybes :: [Maybe a] -> [a]
+Data.Maybe.fromJust :: Maybe a -> a
+Data.Maybe.fromMaybe :: a -> Maybe a -> a
+Data.Maybe.isJust :: Maybe a -> Bool
+Data.Maybe.isNothing :: Maybe a -> Bool
+Data.Maybe.listToMaybe :: [a] -> Maybe a
+Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]
+Data.Maybe.maybeToList :: Maybe a -> [a]
+-- imported via Prelude
+Just :: a -> Maybe a
+data Maybe a = Nothing | Just a
+Nothing :: Maybe a
+maybe :: b -> (a -> b) -> Maybe a -> b
+</screen>
+ <para>
+ This output shows that, in the context of the current session, in the scope
+ of <literal>Prelude</literal>, the first group of items from
+ <literal>Data.Maybe</literal> have not been imported (but are available in
+ fully qualified form in the GHCi session - see <xref
+ linkend="ghci-scope"/>), whereas the second group of items have been
+ imported via <literal>Prelude</literal> and are therefore available either
+ unqualified, or with a <literal>Prelude.</literal> qualifier.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
<term>
- <literal>:continue</literal>
- <indexterm><primary><literal>:continue</literal></primary></indexterm>
- </term>
- <listitem><para>Continue the current evaluation, when stopped at a
- breakpoint.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
<literal>:cmd</literal> <replaceable>expr</replaceable>
<indexterm><primary><literal>:cmd</literal></primary></indexterm>
</term>
<varlistentry>
<term>
+ <literal>:continue</literal>
+ <indexterm><primary><literal>:continue</literal></primary></indexterm>
+ </term>
+ <listitem><para>Continue the current evaluation, when stopped at a
+ breakpoint.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<literal>:ctags</literal> <optional><replaceable>filename</replaceable></optional>
<literal>:etags</literal> <optional><replaceable>filename</replaceable></optional>
<indexterm><primary><literal>:etags</literal></primary>
</term>
<listitem>
<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
+ (<literal>:ctags</literal>) or
+ Emacs-style editors (<literal>:etags</literal>). If
+ 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
<varlistentry>
<term>
- <literal>:def</literal> <replaceable>name</replaceable> <replaceable>expr</replaceable>
+ <literal>:def<optional>!</optional> <optional><replaceable>name</replaceable> <replaceable>expr</replaceable></optional></literal>
<indexterm><primary><literal>:def</literal></primary></indexterm>
</term>
<listitem>
- <para>The command <literal>:def</literal>
- <replaceable>name</replaceable>
- <replaceable>expr</replaceable> defines a new GHCi command
- <literal>:<replaceable>name</replaceable></literal>,
- implemented by the Haskell expression
- <replaceable>expr</replaceable>, which must have type
- <literal>String -> IO String</literal>. When
- <literal>:<replaceable>name</replaceable>
- <replaceable>args</replaceable></literal> is typed at the
- prompt, GHCi will run the expression
- <literal>(<replaceable>name</replaceable>
- <replaceable>args</replaceable>)</literal>, take the
- resulting <literal>String</literal>, and feed it back into
- GHCi as a new sequence of commands. Separate commands in
- the result must be separated by
- ‘<literal>\n</literal>’.</para>
+ <para><literal>:def</literal> is used to define new
+ commands, or macros, in GHCi. The command
+ <literal>:def</literal> <replaceable>name</replaceable>
+ <replaceable>expr</replaceable> defines a new GHCi command
+ <literal>:<replaceable>name</replaceable></literal>,
+ implemented by the Haskell expression
+ <replaceable>expr</replaceable>, which must have type
+ <literal>String -> IO String</literal>. When
+ <literal>:<replaceable>name</replaceable>
+ <replaceable>args</replaceable></literal> is typed at the
+ prompt, GHCi will run the expression
+ <literal>(<replaceable>name</replaceable>
+ <replaceable>args</replaceable>)</literal>, take the
+ resulting <literal>String</literal>, and feed it back into
+ GHCi as a new sequence of commands. Separate commands in
+ the result must be separated by
+ ‘<literal>\n</literal>’.</para>
<para>That's all a little confusing, so here's a few
examples. To start with, here's a new GHCi command which
<literal>:.</literal>, by analogy with the
‘<literal>.</literal>’ Unix shell command that
does the same thing.</para>
+
+ <para>Typing <literal>:def</literal> on its own lists the
+ currently-defined macros. Attempting to redefine an
+ existing command name results in an error unless the
+ <literal>:def!</literal> form is used, in which case the old
+ command with that name is silently overwritten.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
+ <literal>:etags</literal>
+ </term>
+ <listitem>
+ <para>See <literal>:ctags</literal>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<literal>:force <replaceable>identifier</replaceable> ...</literal>
<indexterm><primary><literal>:force</literal></primary></indexterm>
</term>
</varlistentry>
<varlistentry>
+ <term>
+ <literal>:</literal>
+ <indexterm><primary><literal>:</literal></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Repeat the previous command.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+
<term>
<literal>:history [<replaceable>num</replaceable>]</literal>
<indexterm><primary><literal>:history</literal></primary></indexterm>
will be printed. If <replaceable>name</replaceable> has
been loaded from a source file, then GHCi will also display
the location of its definition in the source.</para>
+ <para>For types and classes, GHCi also summarises instances that
+ mention them. To avoid showing irrelevant information, an instance
+ is shown only if (a) its head mentions <replaceable>name</replaceable>,
+ and (b) all the other things mentioned in the instance
+ are in scope (either qualified or otherwise) as a result of
+ a <literal>:load</literal> or <literal>:module</literal> commands. </para>
</listitem>
</varlistentry>
However, we cannot simply pass the arguments to the
<literal>main</literal> function while we are testing in ghci,
as the <literal>main</literal> function doesn't take its
- directly.
+ arguments directly.
</para>
<para>
["foo","bar"]
</screen>
+ <para>
+ We can also quote arguments which contains characters like
+ spaces, and they are treated like Haskell strings, or we can
+ just use Haskell list syntax:
+ </para>
+
+<screen>
+Prelude> :main foo "bar baz"
+["foo","bar baz"]
+Prelude> :main ["foo", "bar baz"]
+["foo","bar baz"]
+</screen>
+
+ <para>
+ Finally, other functions can be called, either with the
+ <literal>-main-is</literal> flag or the <literal>:run</literal>
+ command:
+ </para>
+
+<screen>
+Prelude> let foo = putStrLn "foo" >> System.Environment.getArgs >>= print
+Prelude> let bar = putStrLn "bar" >> System.Environment.getArgs >>= print
+Prelude> :set -main-is foo
+Prelude> :main foo "bar baz"
+foo
+["foo","bar baz"]
+Prelude> :run bar ["foo", "bar baz"]
+bar
+["foo","bar baz"]
+</screen>
+
</listitem>
</varlistentry>
<listitem>
<para>Prints a value without forcing its evaluation.
<literal>:print</literal> may be used on values whose types are
- unkonwn or partially known, which might be the case for local
+ unknown or partially known, which might be the case for local
variables with polymorphic types at a breakpoint. While inspecting
the runtime value, <literal>:print</literal> attempts to
reconstruct the type of the value, and will elaborate the type in
<indexterm><primary><literal>:quit</literal></primary></indexterm>
</term>
<listitem>
- <para>Quits GHCi. You can also quit by typing a control-D
+ <para>Quits GHCi. You can also quit by typing control-D
at the prompt.</para>
</listitem>
</varlistentry>
<indexterm><primary><literal>:set</literal></primary></indexterm>
</term>
<listitem>
- <para>Sets various options. See <xref linkend="ghci-set"/>
- for a list of available options. The
- <literal>:set</literal> command by itself shows which
- options are currently set.</para>
+ <para>Sets various options. See <xref linkend="ghci-set"/> for a list of
+ available options and <xref linkend="interactive-mode-options"/> for a
+ list of GHCi-specific flags. The <literal>:set</literal> command by
+ itself shows which options are currently set. It also lists the current
+ dynamic flag settings, with GHCi-specific flags listed separately.</para>
</listitem>
</varlistentry>
<indexterm><primary><literal>:show modules</literal></primary></indexterm>
</term>
<listitem>
- <para>Show the list of modules currently load.</para>
+ <para>Show the list of modules currently loaded.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>:show packages</literal>
+ <indexterm><primary><literal>:show packages</literal></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Show the currently active package flags, as well as the list of
+ packages currently loaded.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>:show languages</literal>
+ <indexterm><primary><literal>:show languages</literal></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Show the currently active language flags.</para>
</listitem>
</varlistentry>
+
<varlistentry>
<term>
<literal>:show [args|prog|prompt|editor|stop]</literal>
<para>The <literal>:set</literal> command sets two types of
options: GHCi options, which begin with
- ‘<literal>+</literal>” and “command-line”
+ ‘<literal>+</literal>’, and “command-line”
options, which begin with ‘-’. </para>
<para>NOTE: at the moment, the <literal>:set</literal> command
<indexterm><primary>startup</primary><secondary>files, GHCi</secondary>
</indexterm>
- <para>When it starts, GHCi always reads and executes commands from
- <filename>$HOME/.ghci</filename>, followed by
- <filename>./.ghci</filename>.</para>
-
- <para>The <filename>.ghci</filename> in your home directory is
- most useful for turning on favourite options (eg. <literal>:set
- +s</literal>), and defining useful macros. Placing a
- <filename>.ghci</filename> file in a directory with a Haskell
- project is a useful way to set certain project-wide options so you
- don't have to type them everytime you start GHCi: eg. if your
- project uses GHC extensions and CPP, and has source files in three
- subdirectories A B and C, you might put the following lines in
+ <para>When it starts, unless the <literal>-ignore-dot-ghci</literal>
+ flag is given, GHCi reads and executes commands from the following
+ files, in this order, if they exist:</para>
+
+ <orderedlist>
+ <listitem>
+ <para><filename>./.ghci</filename></para>
+ </listitem>
+ <listitem>
+ <para><literal><replaceable>appdata</replaceable>/ghc/ghci.conf</literal>,
+ where <replaceable>appdata</replaceable> depends on your system,
+ but is usually something like <literal>C:/Documents and Settings/<replaceable>user</replaceable>/Application Data</literal></para>
+ </listitem>
+ <listitem>
+ <para>On Unix: <literal>$HOME/.ghc/ghci.conf</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>$HOME/.ghci</literal></para>
+ </listitem>
+ </orderedlist>
+
+ <para>The <filename>ghci.conf</filename> file is most useful for
+ turning on favourite options (eg. <literal>:set +s</literal>), and
+ defining useful macros. Placing a <filename>.ghci</filename> file
+ in a directory with a Haskell project is a useful way to set
+ certain project-wide options so you don't have to type them
+ everytime you start GHCi: eg. if your project uses GHC extensions
+ and CPP, and has source files in three subdirectories A, B and C,
+ you might put the following lines in
<filename>.ghci</filename>:</para>
<screen>
<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
- <filename>.ghci</filename> files are read:</para>
+ startup files files are read:</para>
<variablelist>
<varlistentry>
<indexterm><primary><option>-ignore-dot-ghci</option></primary></indexterm>
</term>
<listitem>
- <para>Don't read either <filename>./.ghci</filename> or
- <filename>$HOME/.ghci</filename> when starting up.</para>
+ <para>Don't read either <filename>./.ghci</filename> or the
+ other startup files when starting up.</para>
</listitem>
</varlistentry>
<varlistentry>
<indexterm><primary><option>-read-dot-ghci</option></primary></indexterm>
</term>
<listitem>
- <para>Read <filename>.ghci</filename> and
- <filename>$HOME/.ghci</filename>. This is normally the
+ <para>Read <filename>./.ghci</filename> and the other
+ startup files (see above). This is normally the
default, but the <option>-read-dot-ghci</option> option may
be used to override a previous
<option>-ignore-dot-ghci</option> option.</para>
<term>I can't use Control-C to interrupt computations in
GHCi on Windows.</term>
<listitem>
- <para>See <xref linkend="ghci-windows"/></para>
+ <para>See <xref linkend="ghci-windows"/>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>The default buffering mode is different in GHCi to GHC.</term>
+ <listitem>
+ <para>
+ In GHC, the stdout handle is line-buffered by default.
+ However, in GHCi we turn off the buffering on stdout,
+ because this is normally what you want in an interpreter:
+ output appears as it is generated.
+ </para>
</listitem>
</varlistentry>
</variablelist>