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>
</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>
</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.