tracing should be controled by a global flag

[phercek]

Instead of ":trace" and ":trace <expr>" command there should be one command ":set trace on/off" and a new command ":debug <expr>".

":set trace" would control a global flag indicating whether tracing should be active or not. If tracing is active then:

• ":continue" would behave like current ":trace",
  
• forcing a value using ":force <expr>" woudl work like current ":trace <expr>" but ignoring breakpoitns,
  
• ":debug <expr>" would work like current ":trace <expr>",
  
• and ":main ..." would start Main.main with tracing on from the very beginning.
  

If tracing is not active then ":continue", ":force", ":main" would behave like they do now and ":debug <expr>" would be the same as current "<expr>".

Reasoning:

I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an <expr> is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if <expr> is typed on the ghci command line directly then tracing is never extended.

This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use ":continue" or ":trace" based on a global flag). This would also allow to start tracing from the very beggining of ":main" instead of setting a break at Main.main with a script set to ":trace" and then running ":main ...".

Related discussion is here:  http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html

I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this.

[phercek]

Actually instead of ":trace on/off" the interface should be rather ":set trace True/False". The reason is relationship of this ticket to ticket #2737. The rest stays as it is.

One more advantage to this approach is that user can check whether tracing is on with ":show trace" (if it is implemented).

[phercek]

Current :steplocal fills in trace history with all source locations executed even when they are not inside the function stepped through using :steplocal. If this is accepted then the source locations outside the localy stepped function should not be logged to trace history if trace is not set to True. Actually I think the locations ouside the locally stepped function should not be added to the trace history even when this is rejected in general.

[phercek]

I asked for ":force <expr>" in the second bullet of the ticket description. It was an insight by accident. It would be really cool if we could force expressions and not only a list of variables. The main reason is user defined conditional breakpoints. A breakpoint condition may contain thunks which need to be forced to compute the condition result. This may result in hitting other breakpoints in nested contexts. This may be required or not. It depends, but it is almost never required if we query some expression containing _result variable. The problem is we stop at the same breakpoint we are just now at. With ":foce <expr>" we could force the breakpoint stop condition first and then query its result by checking the "it" variable.
This is convenient for scripts, not that interesting for manual interaction. But scripts can disable breakpoints before evaluating the stop condition and enable them after the condition evaluation finished so there is a workaround. I just did not add :enable and :disable to my .ghci yet :-/

[phercek]

As I discussed in message  my experience with ghci debugger extensions, the :set trace should have a grammar like this:

 -- should everything be traced?
:set trace (True|False)
-- scopes which should be traced (or should not be traced when ! is present)
:set trace ( (!)? scopeid )*
-- add/remove individual scopeids to/from the trace specification
:set trace (+|-) (!)? scopeid
-- scopeid = ( conid . )* ( varid . )* varid | { breakPointArgs }

scopeId can be specified by its hierarchical identifier or by breakpoint arguments in curly braces.