The Glorious Glasgow Haskell Compilation System User's Guide ...

The Glorious Glasgow Haskell
Compilation System User’s Guide,
Version 6.10.4 25 / 224
[qsort.hs:5:7-47] *Main> :set stop :list
[qsort.hs:5:7-47] *Main> :step
Stopped at qsort.hs:5:14-46
_result :: [Integer]
4
5 main = print (qsort [8, 4, 0, 3, 1, 23, 11, 18])
6
[qsort.hs:5:14-46] *Main>
2.5.3 Nested breakpoints
When GHCi is stopped at a breakpoint, and an expression entered at the prompt triggers a second breakpoint, the new breakpoint
becomes the “current” one, and the old one is saved on a stack. An arbitrary number of breakpoint contexts can be built up in
this way. For example:
[qsort.hs:2:15-46] *Main> :st qsort [1,3]
Stopped at qsort.hs:(1,0)-(3,55)
_result :: [a]
... [qsort.hs:(1,0)-(3,55)] *Main>
While stopped at the breakpoint on line 2 that we set earlier, we started a new evaluation with :step qsort [1,3]. This
new evaluation stopped after one step (at the definition of qsort). The prompt has changed, now prefixed with ..., to indicate
that there are saved breakpoints beyond the current one. To see the stack of contexts, use :show context:
... [qsort.hs:(1,0)-(3,55)] *Main> :show context
--> main
Stopped at qsort.hs:2:15-46
--> qsort [1,3]
Stopped at qsort.hs:(1,0)-(3,55)
... [qsort.hs:(1,0)-(3,55)] *Main>
To abandon the current evaluation, use :abandon:
... [qsort.hs:(1,0)-(3,55)] *Main> :abandon
[qsort.hs:2:15-46] *Main> :abandon
*Main>
2.5.4 The _result variable
When stopped at a breakpoint or single-step, GHCi binds the variable _result to the value of the currently active expression.
The value of _result is presumably not available yet, because we stopped its evaluation, but it can be forced: if the type
is known and showable, then just entering _result at the prompt will show it. However, there’s one caveat to doing this:
evaluating _result will be likely to trigger further breakpoints, starting with the breakpoint we are currently stopped at (if we
stopped at a real breakpoint, rather than due to :step). So it will probably be necessary to issue a :continue immediately
when evaluating _result. Alternatively, you can use :force which ignores breakpoints.
2.5.5 Tracing and history
A question that we often want to ask when debugging a program is “how did I get here?”. Traditional imperative debuggers
usually provide some kind of stack-tracing feature that lets you see the stack of active function calls (sometimes called the
“lexical call stack”), describing a path through the code to the current location. Unfortunately this is hard to provide in Haskell,
because execution proceeds on a demand-driven basis, rather than a depth-first basis as in strict languages. The “stack“ in GHC’s
execution engine bears little resemblance to the lexical call stack. Ideally GHCi would maintain a separate lexical call stack
in addition to the dynamic call stack, and in fact this is exactly what our profiling system does (Chapter 5), and what some
other Haskell debuggers do. For the time being, however, GHCi doesn’t maintain a lexical call stack (there are some technical