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>The search path for finding source files is specified with
+ the <option>-i</option> option on the GHCi command line, like
+ so:</para>
+<screen>ghci -i<replaceable>dir<subscript>1</subscript></replaceable>:...:<replaceable>dir<subscript>n</subscript></replaceable></screen>
+
+ <para>or it can be set using the <literal>:set</literal> command
+ from within GHCi (see <xref
+ linkend="ghci-cmd-line-options">)<footnote><para>Note that in
+ GHCi, and <option>––make</option> mode, the <option>-i</option>
+ option is used to specify the search path for
+ <emphasis>source</emphasis> files, whereas in standard
+ batch-compilation mode the <option>-i</option> option is used to
+ specify the search path for interface files, see <xref
+ linkend="options-finding-imports">.</para> </footnote></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>
<para>HINT: since GHCi will only use a compiled object file if it
can sure that the compiled version is up-to-date, a good technique
when working on a large program is to occasionally run
- <literal>ghc --make</literal> to compile the whole project (say
+ <literal>ghc ––make</literal> to compile the whole project (say
before you go for lunch :-), then continue working in the
interpreter. As you modify code, the new modules will be
interpreted, but the rest of the project will remain
</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>
+ <indexterm><primary><option>––interactive</option></primary></indexterm>
<para>GHCi is invoked with the command <literal>ghci</literal> or
- <literal>ghc --interactive</literal>. One or more modules or
+ <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
</screen>
<para>Or I could define a simple way to invoke
- “<literal>ghc --make Main</literal>” in the
+ “<literal>ghc ––make Main</literal>” in the
current directory:</para>
<screen>
-Prelude> :def make (\_ -> return ":! ghc --make Main")
+Prelude> :def make (\_ -> return ":! ghc ––make Main")
</screen>
</listitem>
</varlistentry>
<varlistentry>
+ <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>
</variablelist>
</sect2>
- <sect2>
+ <sect2 id="ghci-cmd-line-options">
<title>Setting GHC command-line options in GHCi</title>
<para>Normal GHC command-line options may also be set using
</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