</term>
<listitem>
<para>Permits to add, delete or list the breakpoints in a debugging session.
- In order to make this command available, the
- <literal>-fdebugging</literal> flag must be active. The easiest way is to launch
- GHCi with the <literal>-fdebugging</literal> option. For more
- details on how the debugger works, see <xref linkend="ghci-debugger"/>.
</para>
</listitem>
</varlistentry>
Prelude> head li
Just 1
Prelude> :sp li
-li - [Just 1 | _]
+li - Just 1 : _
Prelude> :p li
-li - [Just 1 | (_t2::[Maybe Integer])]
+li - Just 1 : (_t2::[Maybe Integer])
Prelude> last li
Just 5
Prelude> :sp li
The example uses <literal>:print</literal> and <literal>:sprint</literal>
to help us observe how the <literal>li</literal> variable is evaluated progressively as we operate
with it. Note for instance how <quote>last</quote> traverses all the elements of
- the list to compute its result, but without evaluating the individual elements.</para>
- <para>Finally note that the Prolog convention of [head | tail] is used by
- <literal>:sprint</literal> to display unevaluated lists.
+ the list to compute its result, but without evaluating the individual elements.
</para>
</listitem>
</varlistentry>
Prelude> head li
Just 1
Prelude> :sp li
-li - [Just 1 | _]
+li - Just 1 : _
Prelude> last li
Just 5
Prelude> :sp li
</screen>
The example uses <literal>:sprint</literal> to help us observe how the <literal>li</literal> variable is evaluated progressively as we operate
with it. Note for instance how <quote>last</quote> traverses all the elements of
- the list to compute its result, but without evaluating the individual elements.</para>
- <para>Finally note that the Prolog convention of [head | tail] is used by
- <literal>:sprint</literal> to display unevaluated lists.
+ the list to compute its result, but without evaluating the individual elements.
</para>
</listitem>
</varlistentry>
<listitem>
<para>The module must have been loaded interpreted, i.e. not loaded from an <filename>.o</filename> file compiled by ghc </para>
</listitem>
- <listitem>
- <para>The module must have been loaded with the <literal>-fdebugging</literal> flag
- </para></listitem>
</itemizedlist></para>
<sect2><title>Using the debugger</title>
<para>The debugger allows the insertion of breakpoints at specific locations in the source code. These locations are governed by event sites, and not by line as in traditional debuggers such as gdb. </para> <para>
</varlistentry>
</variablelist></para>
</sect2>
- <sect2><title>Limitations</title>
- <para>
- <itemizedlist>
- <listitem><para>
- Implicit parameters (see <xref linkend="implicit-parameters"/>) are only available
- at the scope of a breakpoint if there is a explicit type signature.
- </para></listitem>
- </itemizedlist>
- <itemizedlist>
- <listitem><para>
- Modules compiled by GHCi under the <literal>-fdebugging
- </literal> flag will perform slower: the debugging mode introduces some overhead.
- Modules compiled to object code by ghc are not affected.
- </para></listitem>
- </itemizedlist>
- </para>
+ <sect2><title>Debugging Higher-Order functions</title>
+ It is possible to use the debugger to examine lambdas.
+ When we are at a breakpoint and a lambda is in scope, the debugger cannot show
+ you the source code that constitutes it; however, it is possible to get some
+ information by applying it to some arguments and observing the result.
+
+ The process is slightly complicated when the binding is polymorphic.
+ We will use a example to show the process.
+ To keep it simple, we will use the well known <literal>map</literal> function:
+ <programlisting>
+import Prelude hiding (map)
+
+map :: (a->b) -> a -> b
+map f [] = []
+map f (x:xs) = f x : map f xs
+ </programlisting>
+ We set a breakpoint on <literal>map</literal>, and call it.
+ <programlisting>
+*Main> :break map
+Breakpoint 0 activated at map.hs:(4,0)-(5,12)
+*Main> map Just [1..5]
+Stopped at map.hs:(4,0)-(5,12)
+_result :: [b]
+x :: a
+f :: a -> b
+xs :: [a]
+ </programlisting>
+ GHCi tells us that, among other bindings, <literal>f</literal> is in scope.
+ However, its type is not fully known yet,
+ and thus it is not possible to apply it yet to any
+ arguments. Nevertheless, observe that the type of its first argument is the
+ same as the type of <literal>x</literal>, and its result type is the
+ same as the type of <literal>_result</literal>.
+ The debugger has some intelligence built-in to update the type of
+ <literal>f</literal> whenever the types of <literal>x</literal> or
+ <literal>_result</literal> are reconstructed. So what we do in this scenario is
+ force <literal>x</literal> a bit, in order to recover both its type
+ and the argument part of <literal>f</literal>.
+ <programlisting>
+*Main> seq x ()
+*Main> :print x
+x = 1
+ </programlisting>
+ We can check now that as expected, the type of <literal>x</literal>
+ has been reconstructed, and with it the
+ type of <literal>f</literal> has been too:
+ <programlisting>
+*Main> :t x
+x :: Integer
+*Main> :t f
+f :: Integer -> b
+ </programlisting>
+ From here, we can apply f to any argument of type Integer and observe the
+ results.
+ <programlisting><![CDATA[
+*Main> let b = f 10
+*Main> :t b
+b :: b
+*Main> b
+<interactive>:1:0:
+ Ambiguous type variable `b' in the constraint:
+ `Show b' arising from a use of `print' at <interactive>:1:0
+*Main> :p b
+b = (_t2::a)
+*Main> seq b ()
+()
+*Main> :t b
+b :: a
+*Main> :p b
+b = Just 10
+*Main> :t b
+b :: Maybe Integer
+*Main> :t f
+f :: Integer -> Maybe Integer
+*Main> f 20
+Just 20
+*Main> map f [1..5]
+[Just 1, Just 2, Just 3, Just 4, Just 5]
+ ]]></programlisting>
+ In the first application of <literal>f</literal>, we had to do
+ some more type reconstruction
+ in order to recover the result type of <literal>f</literal>.
+ But after that, we are free to use
+ <literal>f</literal> normally.
</sect2>
<sect2><title>Tips</title>
<variablelist>
- <varlistentry><term>* Use PRAGMAs to fine tune which modules are loaded under debugging mode</term>
- <listitem>
- <programlisting>{-# OPTIONS_GHC -fdebugging #-}</programlisting>
- </listitem>
- </varlistentry>
<varlistentry> <term>* Repeated use of <literal>seq</literal> and
<literal>:print</literal> may be necessary to observe unevaluated
untyped bindings</term>
<listitem><para><programlisting>
type MyLongType a = [Maybe [Maybe a]]
-main:Main> :m +GHC.Exts
-main:Main> main
+*Main> :m +GHC.Exts
+*Main> main
Local bindings in scope:
x :: a
Main.hs:15> let x' = unsafeCoerce x :: MyLongType Bool
Note that a wrong coercion will likely result in your debugging session being interrupted by a segmentation fault
</para></listitem>
</varlistentry>
- <varlistentry> <term> * The undocumented (and unsupported) :force command </term>
+ <varlistentry> <term> * The <literal>:force</literal> command </term>
<listitem><para>
equivalent to <literal> :print</literal> with automatic
<literal>seq</literal> forcing,
</para></listitem>
</varlistentry>
</variablelist>
- </sect2></sect1>
+ </sect2>
+ <sect2><title>Limitations</title>
+ <para>
+ <itemizedlist>
+ <listitem><para>
+ Implicit parameters (see <xref linkend="implicit-parameters"/>) are only available
+ at the scope of a breakpoint if there is a explicit type signature.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+ </sect1>
<sect1 id="ghci-dot-files">
<title>The <filename>.ghci</filename> file</title>
<indexterm><primary><filename>.ghci</filename></primary><secondary>file</secondary>
</sect1>
+ <sect1 id="ghci-obj">
+ <title>Compiling to object code inside GHCi</title>
+
+ <para>By default, GHCi compiles Haskell source code into byte-code
+ that is interpreted by the runtime system. GHCi can also compile
+ Haskell code to object code: to turn on this feature, use the
+ <option>-fobject-code</option> flag either on the command line or
+ with <literal>:set</literal> (the option
+ <option>-fbyte-code</option> restores byte-code compilation
+ again). Compiling to object code takes longer, but typically the
+ code will execute 10-20 times faster than byte-code.</para>
+
+ <para>Compiling to object code inside GHCi is particularly useful
+ if you are developing a compiled application, because the
+ <literal>:reload</literal> command typically runs much faster than
+ restarting GHC with <option>--make</option> from the command-line,
+ because all the interface files are already cached in
+ memory.</para>
+
+ <para>There are disadvantages to compiling to object-code: you
+ can't set breakpoints in object-code modules, for example. Only
+ the exports of an object-code module will be visible in GHCi,
+ rather than all top-level bindings as in interpreted
+ modules.</para>
+ </sect1>
+
<sect1 id="ghci-faq">
<title>FAQ and Things To Watch Out For</title>
projects / ghc-hetmet.git / blobdiff