failure implementing :next command in ghci

[Simon Marlow]

Peter Hercek wrote:
> Hi,
> 
> So I wanted to give implementing :next ghci debugger command a shot. It 
> looked easy and I could use it. Moreover it would give me an easy way to 
> implement dynamic stack in ghci (using similar approach as used for 
> trace) ... well if I would feel like that since I was a bit discouraged 
> about it. The problem is I failed miserably. I still think it is easy to 
> do. I just do not know how to create correct arguments for 
> rts_breakpoint_io_action and I have given up finding up myself for now.
> 
> 
> The proposed meaning for :next
> 
> Lets mark dynamic stack size at a breakpoint (at which we issue :next) 
> as breakStackSize and its selected expression as breakSpan. Then :next 
> would single step till any of these is true:
> 1) current dynamic stack size is smaller than breakStackSize
> 2) current dynamic stack size is equal to breakStackSize and the current 
> selected expression is not a subset of breakSpan

So what happens if the stack shrinks and then grows again between two 
breakpoints?  Presumably :next wouldn't notice.  I think you'd be better 
off implementing this with a special stack frame, so that you can guarantee 
to notice when the current "context" has been exited.  Still, I'm not 
completely sure that :next really makes sense... but I haven't thought 
about it in any great detail.

> I hope the above would make good sense but I do not really know since 
> maybe rts does some funny things with stack sometimes. If you think the 
> proposed behavior is garbage let me know why so that I do not waste more 
> time with this :)

Yes the RTS does do "funny thing" with the stack sometimes.  The stack can 
shrink as a result of adjacent update frames being coalesced ("stack 
squeezing").  Using a stack frame instead of a "low water mark" would be 
immune to this.

Cheers,
	Simon