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
