Malcolm Wallace wrote:
In a lazy language, the dynamic stack rarely tells you anything of
interest for debugging. For the value at the top of the stack, you get
one of many possible _demand_ chains, rather than the creation chain.
The demanding location is pretty-much guaranteed not to be the site of
the bug.
But you can think of the lexical call stack as what _would_ have been
the dynamic call stack, if only the language were completely strict
rather than lazy. Most people find the latter notion more intuitive for
the purposes of finding program errors.
OK, maybe I understand it. If the lexical stack would give me access to
local variables for all its frames it would be probably better. In the
current situation where I have only access to the free vars in the
current expression it is not that useful. I mean for my code I know what
is the creation chain. This may be different if I would debug somebody
else's code. But when debugging my code I sometimes lose track what
demand chain I'm in or why the hell I'm at the given location at all.
Dynamic stack would help here a lot and it would help me to better
understand lazy behavior of my code. The creation behavior is rather
clear to me because it is explicit in the code. The lazy behavior may be
more tough because it is implicit.
Sure, but the plan to maintain an approximate debugging dynamic stack
depends on one thing:
There is no need to approximate the dynamic stack. It is directly
available to the RTS, in full detail.
Well, but this would be the exact stack. It would be great to see how
ghci works but I'm not sure how much helpful it would be for debugging.
I'm afraid it would have the same problem as _return binding (bug
#1531). In my code _return is mostly wrong. I'm not even checking it out
any more.
Thanks,
Peter.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
