[Rd] Suggestion: simplify trace() interface

[Duncan Murdoch]

The trace() function is very nice for setting breakpoints or other 
debugging code in functions and methods, but its interface is 
confusingly complicated.

For example, there was a question on StackOverflow recently that led to 
this observation:

    trace(stats::predict.lm, edit = TRUE)

will allow breakpoints to be set in stats::predict.lm, but they will 
only be seen if that method is called directly, not indirectly via 
stats::predict on an lm object. If stats is on the search list,

    trace(predict.lm, edit = TRUE)

does the same thing as you would expect.

On the other hand,

    trace(stats:::predict.lm, edit = TRUE)

sets the breakpoint so it works in predict() calls, but *not* on direct 
calls.

I can see that sometimes you would want to differentiate between those 
two ways of calling predict.lm, but I would think that normally you'd 
want both kinds to be debugged.

There's also an argument "where" that allows you to limit the tracing, 
e.g. an example allows you to trace calls to lm() coming from the nlme 
package (presumably by tracing only the import, but I haven't debugged 
it carefully).

Wouldn't it make sense for "where" to be the *only* way to limit tracing 
to some copies of the function, and if "where" is omitted, trace() 
should attempt to modify all copies?

Duncan Murdoch