could ghci debugger search for free variables better?

[Peter Hercek]

Simon Marlow wrote:
> Peter Hercek wrote:
<---cut--->
>> I see that it is not a good idea to keep references to all the
>>  variables in scope but maybe few improvements are possible:
>>
>> 1) As there is :steplocal, there should be also :tracelocal.
>>    It would keep history of evaluations within given function
>>    then when user asks for a variable it would be searched
>>    first in the selected expression and if not found in the
>>    expressions from the tracelocal history. If the result
>>    would be printed from tracelocal history it should be indicated
>>    so in the output. This would avoid the tedious task of
>>    searching the trace history manually and moreover it would
>>    limit the history to the interesting parts (so hopefully
>>    the depth of 50 would be enough). The results from the
>>    tracelocal history may not be from the expected scope
>>    sometimes but the same problem is with "printf debugging".
> 
> Good suggestion - please submit it via the bugtracker,
> 
> http://hackage.haskell.org/trac/ghc/newticket?type=feature+request

Here it is:
http://hackage.haskell.org/trac/ghc/ticket/2737

>> 2) I noticed only now that I do not know how to script
>>    breakpoints. I tried
>>    :set stop if myFreeVar == 666 then :list else :continue
>>    ... and it did not work. My goal was to create a conditional
>>    breakpoint. I also wanted to use it instead of "printf
>>    debugging" using something like
>>    :set stop { :force myFreeVar; :continue }
>>    Ideally it should be possible to attach
>>    different script for each breakpoint and the functions
>>    for controlling debugger should be available in the
>>    Haskell. I would expect this is already partially possible
>>    now (using :set stop) and possibly some functions from
>>    ghci api which correspond to ghci commands (like :set etc.).
>>    But I do not know how, any pointers from experienced ghci
>>    debugger users?
> 
> I think you want :cmd.  e.g.
> 
> :set stop :cmd if myFreeVar == 666 then return ":list" else return 
> ":continue"

Yes! That works good enough, and I can set a different script
  for each breakpoint with ":set stop N <cmd>"! Thanks. The only
  thing I still miss here is a way to suppress the default output
  when a breakpoint (which has a script attached?) is hit.

As for as the rest of the message. Those are possible bugs.
  If I can reduce them to few tens of lines of a test, I'll
  post the bug reports. I use Archlinux and the last (non-testing)
  version of ghc there is ghc-6.8.2. Do you accept bug reports
  against it or do you need them against 6.10.1rc1 only?

Thanks for help,
   Peter.


>> Ghci debugger did not know some functions in my code which
>>  I would expect it to know; e.g. field selection functions
>>  from a record which is not exported from the module but
>>  which are available withing module. Is this expected?
>>  (I did not have any *.hi *.o files around when ghci did run
>>  the code.)
> 
> It could be a bug, if you could figure out how to reproduce it and 
> submit a bug report that would be great.
> 
>> Och and sometimes it did not recognize a free variable in
>>  the selected expression. The code looked like
>>  let myFn x = x `div` getDivisor state > 100 in
>>  if myFn xxx then ...
>>  the expression "myFn xxx" was selected while browsing trace
>>  history but xxx was not recognized, but when I browsed into
>>  myFn definition in the trace log the x (which represented
>>  the same value) was recognized. Is this expected?
> 
> Again, please submit a bug report.  The debugger is supposed to give you 
> access to all of the free variables of the current expression.
> 
> Cheers,
>     Simon