ghci debugger: showing function argumetns when stopped at its definition
Hi, It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case it should provide bindings of the function arguments. Is it doable without bad consequences? Looks to me like it should not result in some memory leak problems though I do not have idea whether it is hard to do. The reason I want it is that if it would be available I could put a break point which never stops and only continues at the start of a function I'm interested in. Then If I later stop somewhere in the function I have a pretty good chance that the correct arguments are stored in the trace history and I could retrieve them. E.g. with my GhciExt it would be as simple as: -- to strobe function arguments :count 0 <QualifiedFncName> -- and to look them up later when stopped somewhere -- in the function I could just use :locate :back <QualifiedFncName> -- ... or for a specific argument value :find :back <ArgumentName> If you are interested GhciExt is available here: http://www.hck.sk/users/peter/pub/ But other users could do it too in a bit more complicated way (e.g. by stopping at the function start manually and then continuing and then searching the trace history manually again). Of course I can make sure the function arguments get to the history even now but in much more complicated way (by putting a non-stopping break point at each first use of each argument). The problem with this approach is that: * one must look up all the places in the source code * some of the places may not be hit before we stop at some interesting place in the function so some arguments would not be visible yet Thanks, Peter.
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it). In this case it should provide bindings of the function arguments. Is it doable without bad consequences? Looks to me like it should not result in some memory leak problems though I do not have idea whether it is hard to do.
The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in f x 0 = x f 0 x = x when we stop at f, what do you want to see? I think the current policy is to stop at the outer level (no bindings), and the next breakpoint is on the right-hand side of the equation taken, with the appropriate free variables bound. I suppose you could use a scheme whereby the bindings are named if there is only one equation, or otherwise use "_arg1" "_arg2", etc. Cheers, Simon
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it).
The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in
f x 0 = x f 0 x = x
when we stop at f, what do you want to see?
Right, I did not realize this problem. But your idea of using _arx<N> naming in case of more equations seems best to me. I would still like to have it available. So it looks doable without bad consequences. Now, the question is: Is there any support for it except me? Thanks, Peter.
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it).
The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in
f x 0 = x f 0 x = x
when we stop at f, what do you want to see?
Right, I did not realize this problem. But your idea of using _arx<N> naming in case of more equations seems best to me. I would still like to have it available.
Even in one equation, pattern match can make it undesirable. Say, in fromJust (Just x) = ... doesn't allow you access to the argument directly. Can _argN be provided in *all* cases (possibly in addition to other bindings)? -Isaac
On Mon, 13 Jul 2009 20:48:42 -0400, Isaac Dupree wrote:
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it).
The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in
f x 0 = x f 0 x = x
when we stop at f, what do you want to see?
Right, I did not realize this problem. But your idea of using _arx<N> naming in case of more equations seems best to me. I would still like to have it available.
Even in one equation, pattern match can make it undesirable. Say, in fromJust (Just x) = ... doesn't allow you access to the argument directly. Can _argN be provided in *all* cases (possibly in addition to other bindings)?
I was thinking about adding _argN always too. If it is done in addition to other binding (which are not ambiguous) then even better. Regardless I'm fine with any solution which allows me to access arguments more easily (i.e. without tracing on (to manually search for call site) or without trying to mark all first usages). Peter.
Peter Hercek wrote:
Simon Marlow wrote:
On 10/07/2009 15:31, Peter Hercek wrote:
Hi,
It would be cool if ghci debugger could grab not only the free variables in the selected expression but in one case a bit more. The case is when we stop at a function definition the first time (when just entering it).
The problem is that functions can be defined with multiple equations, each giving different names for the arguments. e.g. in
f x 0 = x f 0 x = x
when we stop at f, what do you want to see?
Right, I did not realize this problem. But your idea of using _arx<N> naming in case of more equations seems best to me. I would still like to have it available.
So it looks doable without bad consequences. Now, the question is: Is there any support for it except me?
No objections here. Cheers, Simon
participants (3)
-
Isaac Dupree -
Peter Hercek -
Simon Marlow