failure implementing :next command in ghci

[Peter Hercek]

Simon Marlow wrote:
> Peter Hercek wrote:
>> 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.

Yes, if there is no breakpoint in between I would not notice. I did not 
expect this can happen though. I thought that to add a frame on the 
stack this must be done within an expression (which is going to be 
forced) and the expression should be a breakpoint location. If it is so 
negligible that it does not have a breakpoint location associated then 
even the things it is calling should be negligible.
Where is an error in this?

> 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.

This would be robust but I do not have knowledge to do it yet. If I 
understand you correctly this means that before executing a BCO which we 
are going to break at, we must prepare for a possible :next. So 
regardless whether :next is going to be issued by the user or not we 
would add a frame which represents a return to a function which:
a) if user issued :next it enables all breakpoints so that we stop at 
the next breakpoint
b) if user did not issue a break it would not do anything (just return)

We could decide not to insert the frame when we are only tracing. But if 
I would want to track a simulated dynamic stack I would need to insert 
this stack frame at the start of each breakpoint (when dynamic stack 
tracing would be on). Does not sound that good.

>> 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").

OK, so it looks like either switching off the squeezing (if shrinking 
and growing stack between breakpoints/ticks is not such an issue), or 
inserting a stack frame.
Does the "stack squeezing" happen during garbage collection?


Thanks,
Peter.