you're famililar with Hugs<indexterm><primary>Hugs</primary>
</indexterm>, then you'll be right at home with GHCi. However, GHCi
also has support for interactively loading compiled code, as well as
- supporting all<footnote><para>except the FFI, at the moment</para>
+ supporting all<footnote><para>except <literal>foreign export</literal>, at the moment</para>
</footnote>the language extensions that GHC provides.</para>
<indexterm><primary>FFI</primary><secondary>GHCi support</secondary></indexterm>
<indexterm><primary>Foreign Function Interface</primary><secondary>GHCi support</secondary></indexterm>
in the same directory and you can't call them all
<filename>Main.hs</filename>.</para>
+ <para>One consequence of the way that GHCi follows dependencies
+ to find modules to load is that every module must have a source
+ file. The only exception to the rule is modules that come from
+ a package, including the <literal>Prelude</literal> and standard
+ libraries such as <literal>IO</literal> and
+ <literal>Complex</literal>. If you attempt to load a module for
+ which GHCi can't find a source file, even if there are object
+ and interface files for the module, you'll get an error
+ message.</para>
+
<para>One final note: if you load a module called Main, it must
contain a <literal>main</literal> function, just like in
GHC.</para>
</sect2>
</sect1>
- <sect1>
+ <sect1 id="ghci-invokation">
<title>Invoking GHCi</title>
<indexterm><primary>invoking</primary><secondary>GHCi</secondary></indexterm>
<indexterm><primary><option>--interactive</option></primary></indexterm>
<para>GHCi is invoked with the command <literal>ghci</literal> or
- <literal>ghc --interactive</literal>. A module or filename can
- also be specified on the command line; this instructs GHCi to load
- the that module or filename (and all the modules it depends on),
- just as if you had said <literal>:load
- <replaceable>module</replaceable></literal> at the GHCi prompt
- (see <xref linkend="ghci-commands">). For example, to start GHCi
- and load the program whose topmost module is in the file
- <literal>Main.hs</literal>, we could say:</para>
+ <literal>ghc --interactive</literal>. One or more modules or
+ filenames can also be specified on the command line; this
+ instructs GHCi to load the specified modules or filenames (and all
+ the modules they depend on), just as if you had said
+ <literal>:load <replaceable>modules</replaceable></literal> at the
+ GHCi prompt (see <xref linkend="ghci-commands">). For example, to
+ start GHCi and load the program whose topmost module is in the
+ file <literal>Main.hs</literal>, we could say:</para>
<screen>
$ ghci Main.hs
</screen>
- <para>Note: only <emphasis>one</emphasis> module name or filename
- may be given on the command line.</para>
-
<para>Most of the command-line options accepted by GHC (see <xref
linkend="using-ghc">) also make sense in interactive mode. The ones
that don't make sense are mostly obvious; for example, GHCi
<variablelist>
<varlistentry>
+ <term><literal>:add</literal>
+ <replaceable>module</replaceable> ...</term>
+ <indexterm><primary><literal>:add</literal></primary></indexterm>
+ <listitem>
+ <para>Add <replaceable>module</replaceable>(s) to the
+ current <firstterm>target set</firstterm>, and perform a
+ reload.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><literal>:cd</literal> <replaceable>dir</replaceable></term>
<indexterm><primary><literal>:cd</literal></primary></indexterm>
<listitem>
</varlistentry>
<varlistentry>
- <term><literal>:load</literal> <replaceable>module</replaceable></term>
+ <term><literal>:info</literal> <replaceable>name</replaceable>
+ ...</term>
+ <indexterm><primary><literal>:info</literal></primary>
+ </indexterm>
+ <listitem>
+ <para>Displays information about the given name(s). For
+ example, if <replaceable>name</replaceable> is a class, then
+ the class methods and their types will be printed; if
+ <replaceable>name</replaceable> is a type constructor, then
+ its definition will be printed; if
+ <replaceable>name</replaceable> is a function, then its type
+ 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>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>:load</literal>
+ <replaceable>module</replaceable> ...</term>
<indexterm><primary><literal>:load</literal></primary></indexterm>
<listitem>
- <para>Recursively loads <replaceable>module</replaceable>
- (which may be a module name or filename), and all the
- modules it depends on. All previously loaded modules are
- forgotten. The module <replaceable>module</replaceable> is
- known as the <firstterm>target</firstterm>.</para>
+ <para>Recursively loads the specified
+ <replaceable>module</replaceable>s, and all the modules they
+ depend on. Here, each <replaceable>module</replaceable>
+ must be a module name or filename, but may not be the name
+ of a module in a package.</para>
+
+ <para>All previously loaded modules, except package modules,
+ are forgotten. The new set of modules is known as the
+ <firstterm>target set</firstterm>.</para>
+
+ <para>After a <literal>:load</literal> command, the current
+ context is set to:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><replaceable>module</replaceable>, if it was loaded
+ successfully, or</para>
+ </listitem>
+ <listitem>
+ <para>the most recently successfully loaded module, if
+ any other modules were loaded as a result of the current
+ <literal>:load</literal>, or</para>
+ </listitem>
+ <listitem>
+ <para><literal>Prelude</literal> otherwise.</para>
+ </listitem>
+ </itemizedlist>
</listitem>
</varlistentry>
<term><literal>:reload</literal></term>
<indexterm><primary><literal>:reload</literal></primary></indexterm>
<listitem>
- <para>Attempts to reload the current target (see
- <literal>:load</literal>) if it, or any module it depends
- on, has changed. Note that this may entail loading new
- modules, or even dropping modules which are no longer
- indirectly required by the target.</para>
+ <para>Attempts to reload the current target set (see
+ <literal>:load</literal>) if any of the modules in the set,
+ or any dependent module, has changed. Note that this may
+ entail loading new modules, or dropping modules which are no
+ longer indirectly required by the target.</para>
</listitem>
</varlistentry>
</sect2>
</sect1>
- <sect1>
+ <sect1 id="ghci-dot-files">
<title>The <filename>.ghci</filename> file</title>
<indexterm><primary><filename>.ghci</filename></primary><secondary>file</secondary>
</indexterm>
a static one, but in fact it works to set it using
<literal>:set</literal> like this. The changes won't take effect
until the next <literal>:load</literal>, though.)</para>
+
+ <para>Two command-line options control whether the
+ <filename>.ghci</filename> files are read:</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>-ignore-dot-ghci</option></term>
+ <indexterm><primary><option>-ignore-dot-ghci</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Don't read either <filename>./.ghci</filename> or
+ <filename>$HOME/.ghci</filename> when starting up.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-read-dot-ghci</option></term>
+ <indexterm><primary><option>-read-dot-ghci</option></primary>
+ </indexterm>
+ <listitem>
+ <para>Read <filename>.ghci</filename> and
+ <filename>$HOME/.ghci</filename>. 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>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
</sect1>
<sect1>
</varlistentry>
<varlistentry>
- <term><literal>System.exit</literal> causes GHCi to exit!</term>
- <indexterm><primary><literal>System.exit</literal></primary><secondary>in
- GHCi</secondary></indexterm>
- <listitem>
- <para>Yes, it does.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term><literal>System.getArgs</literal> returns GHCi's command
line arguments!</term>
<listitem>
</varlistentry>
<varlistentry>
- <term>The interpreter can't load modules with FFI
+ <term>The interpreter can't load modules with foreign export
declarations!</term>
<listitem>
<para>Unfortunately not. We haven't implemented it yet.
</varlistentry>
<varlistentry>
- <term>Hugs has a <literal>:add</literal> command for adding
- modules without throwing away any that are already loaded.
- Why doesn't this work in GHCi?</term>
- <listitem>
- <para>We haven't implemented it yet. Sorry about that.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term><literal>-O</literal> doesn't work with GHCi!</term>
<indexterm><primary><option>-O</option></primary>
</indexterm>
properly with GHC's concurrency model.</para>
</listitem>
</varlistentry>
- </variablelist>
+ <varlistentry>
+ <term>After using <literal>getContents</literal>, I can't use
+ <literal>stdin</literal> again until I do
+ <literal>:load</literal> or <literal>:reload</literal>.</term>
+
+ <listitem>
+ <para>This is the defined behaviour of
+ <literal>getContents</literal>: it puts the stdin Handle in
+ a state known as <firstterm>semi-closed</firstterm>, wherein
+ any further I/O operations on it are forbidden. Because I/O
+ state is retained between computations, the semi-closed
+ state persists until the next <literal>:load</literal> or
+ <literal>:reload</literal> command.</para>
+
+ <para>You can make <literal>stdin</literal> reset itself
+ after every evaluation by giving GHCi the command
+ <literal>:set +r</literal>. This works because
+ <literal>stdin</literal> is just a top-level expression that
+ can be reverted to its unevaluated state in the same way as
+ any other top-level expression (CAF).</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
</sect1>
</chapter>
projects / ghc-hetmet.git / blobdiff