Hi GHCi users,

The example is at the end of this email.
I think it is a bug that the second part (:continue) of the command `:cmd return "rv\n:continue"' is executed in a different context than the first part (rv (request for the value of rv variable)). Notice that we did not stop at breakpoint 1 (line 7). Well, the stop happened but it continued immediately because of queued :continue command. But the command was queued in the context of breakpoint 0 and not breakpoint 1.
Is it a feature or a bug?
If it is a feature it is not good for scripting breakpoints :-/ ... and I do not see an easy way to work around it.

Thanks,
  Peter.

PS: I owe responses to some of you on this list, but I must check some docs or do some tests first so I hope I'll answer during weekend at worst.


status:0 peter@metod [716] ~/tmp
% grep -n '^' b.hs
1:fn :: Int -> Int
2:fn x =
3:  let rv = add x 1 in
4:  rv
5:
6:add :: Int -> Int -> Int
7:add a b = a + b
status:0 peter@metod [717] ~/tmp
% ghci b.hs       
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main             ( b.hs, interpreted )
Ok, modules loaded: Main.
*Main> :set stop :list
*Main> :break 4
Breakpoint 0 activated at b.hs:4:2-3
*Main> :break 7
Breakpoint 1 activated at b.hs:7:0-14
*Main> fn 100
Stopped at b.hs:4:2-3
_result :: Int = _
rv :: Int = _
3    let rv = add x 1 in
4    rv
5  
[b.hs:4:2-3] *Main> :cmd return "rv\n:continue"
Stopped at b.hs:7:0-14
_result :: Int = _
6  add :: Int -> Int -> Int
7  add a b = a + b
8  
101
[b.hs:4:2-3] *Main> :continue
101
*Main> :q
Leaving GHCi.
status:0 peter@metod [718] ~/tmp
%