Simon Marlow wrote:
Perhaps you're already aware of this wiki page, but I'll post the link anyway:
I was writing about a way how to maintain the stack as described in point 6 of the page (provided that point is about dynamic stack). The point only says it would be fine to have stack without hints how to do it.
The dynamic call stack is already present, in the form of the runtime execution stack. For debugging you might want to track more information than we store on this stack, however.
Does GHC have the same stack for both return addresses and arguments or are they separated? I assumed separated but I'm in doubt now. Do you have enough (debug) information there already to at least match arguments to function calls? My point is that having an exact stack is probably better if it is not too hard to do. On the other side if there is not enough debug information already present, it may be easier to to maintain an approximate debugging stack because most of the information needed for it is already in there. As I already said in other emails, I would rather choose dynamic stack over lexical one if I was forced to choose only one of them. Actually, I almost do not care about lexical stack and still do not understand why people want it. Even for profiling it looks fishy because at least in some cases it behaves like a dynamic stack (time is attributed where expression is forced not where the expression looks to be in the lexical stack).
You seem to have a plan for maintaining a dynamic stack for debugging, perhaps you could flesh out the details in a wiki page, mainly to ensure that we're discussing the same thing?
Sure, but the plan to maintain an approximate debugging dynamic stack depends on one thing: The number of items (continuations) on the return stack from the beginning of /case tick<n> of {_->e}/ to the moment when we can check the count of items in the return stack inside /tick<n>/ is constant and known for a given runtime version of ghc. Or variable but known for each call individually. This is important to find out the number of return addresses on the return stack just before the execution of /case tick<n> of {_->e}/. This looks achievable to me, but maybe it is not. Do you think the condition can be satisfied without too much work? If yes, I'll go on to write the page. If not it would be waste of time. Thanks, Peter.