From 8fcfc8d6e42ea5bf49422024bc71d3728ee97db9 Mon Sep 17 00:00:00 2001 From: Pepe Iborra Date: Wed, 22 Aug 2007 08:42:54 +0000 Subject: [PATCH] Better document :stepover and its limitations :stepover only works lexically locally, in the context of the current expression. I have tried to make this point clear in the users guide with an example. --- compiler/ghci/InteractiveUI.hs | 2 +- docs/users_guide/ghci.xml | 47 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 46 insertions(+), 3 deletions(-) diff --git a/compiler/ghci/InteractiveUI.hs b/compiler/ghci/InteractiveUI.hs index d7de940..e868d14 100644 --- a/compiler/ghci/InteractiveUI.hs +++ b/compiler/ghci/InteractiveUI.hs @@ -186,7 +186,7 @@ helpText = " :sprint [ ...] simplifed version of :print\n" ++ " :step single-step after stopping at a breakpoint\n"++ " :step single-step into \n"++ - " :stepover single-step without following function applications\n"++ + " :stepover (locally) single-step over function applications"++ " :trace trace after stopping at a breakpoint\n"++ " :trace trace into (remembers breakpoints for :history)\n"++ diff --git a/docs/users_guide/ghci.xml b/docs/users_guide/ghci.xml index a8ebbd7..82ee330 100644 --- a/docs/users_guide/ghci.xml +++ b/docs/users_guide/ghci.xml @@ -1125,9 +1125,48 @@ _result :: IO () expr is ommitted, then it single-steps from the current breakpoint. :stepover works similarly. - + + In the current version of the debugger, :stepover + is limited to work locally in the lexical sense, that is in the context + of the current expression body. + When you run to the end of the expression, :stepover + stops working and switches to behave like regular :step. + This means + that it will fail to step over the last function application. As a result, + currently :stepover works great for monadic code, but + interacts less perfectly with pure code. For example, if stopped at the + line 2, on the entire expression + qsort left ++ [a] ++ qsort right: + +... [qsort2.hs:2:15-46] *Main> :step +Stopped at qsort2.hs:2:15-46 + +... [qsort2.hs:2:15-46] *Main> :list +2 qsort (a:as) = qsort left ++ [a] ++ qsort right + + + The first :stepover will step over the first + qsort recursive call, as expected. The second one + will step over the evaluation of [a], again as + expected. However, the third one has lexically run out + of the current expression, and will behave like regular + :step, performing one step of lazy evaluation and + stopping at the next breakpoint. In this case it is indeed the second + recursive application of qsort. + +[qsort2.hs:2:36-46] *Main> :stepover +Warning: no more breakpoints in this function body, switching to :step +Stopped at qsort2.hs:(1,0)-(3,55) + +[qsort2.hs:2:36-46] *Main> :list +_result :: [a] +1 qsort [] = [] +2 qsort (a:as) = qsort left ++ [a] ++ qsort right +3 where (left,right) = (filter (<=a) as, filter (>a) as) + The :list command is particularly useful when - single-stepping, to see where you currently are: + single-stepping, to see where you currently are, as just shown + in the above example. [qsort.hs:5:7-47] *Main> :list @@ -1489,6 +1528,10 @@ Just 20 CAF (e.g. main), stop at a breakpoint, and ask for the value of the CAF at the prompt again. + :stepover only works lexically locally, in the + body of the current expression. As a result, it can be rather impredictable + when used in pure functional code, as opposed to monadic code. + Implicit parameters (see ) are only available at the scope of a breakpoint if there is an explicit type signature. -- 1.7.10.4