#2737: add :tracelocal to ghci debugger to trace only the expressions in a given
function
---------------------------------+------------------------------------------
Reporter: phercek | Owner:
Type: feature request | Status: new
Priority: normal | Component: GHCi
Version: 6.8.3 | Severity: normal
Keywords: debugger | Testcase:
Architecture: Unknown/Multiple | Os: Unknown/Multiple
---------------------------------+------------------------------------------
As there is :steplocal, there should be also :tracelocal. It would keep
history of evaluations within a given function. When an acces to a
variable is needed it would be searched first in the selected expression
and if not found the search would continue in the expressions from the
trace history. If the value used would originate from the trace history it
should be indicated so in the output: at the end or beginning of the
output there would be the list of identifiers which values were taken from
trace history. 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 current depth of 50 would be enough).
:tracelocal should take an optional argument which defines the function to
trace. Similar options as for a breakpoint specification (:break command)
would be fine. It might be usefull to associate the tracelocal trace with
breakpoint and having an option to set it on for given breakpoint (in such
a case it would be possible to add tracelocal flag for a breakpoint).
Note that the results from the trace history may not be from the expected
scope but the same problem is with "printf debugging" which is an
efficient way to debug Haskell programs now too. The list of identifiers
which were taken from trace history (while evaluating an interactively
entered expression) should be provided because of the posibility to get
values from an unexpected scope.
This should be a cheap way to make ghci debugger better than just plain
"printf debugging", especially when used together with scriptable
breakpoints (where one could script each breakpoint individually - not
only all of them at once with :set stop). The best solution from user
point of view would be just to provide access to all the variables which
are in scope in a given expression (not just the free ones) but it is
believed that it would introduce too much overhead.
Here is the url of the thread head where this proposal started to evolve:
http://www.haskell.org/pipermail/glasgow-haskell-
users/2008-October/015840.html
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2737>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
