41;309;0c> Why does debug() enter Browse[3] here at all, and why does it happen the
first time and not the second? This seems unexpected to me, and has undesirable effects for ESS users (that I reported here - https://stat.ethz.ch/pipermail/ess-help/2013-June/009154.html - but just realized my post to r-devel didn't make it through when I tried to report it back then).
Fun <- function(n) print(n) debug(Fun) Fun(2)
debugging in: Fun(2)
debug: print(n)
Browse[2]> {n+2}
debug at #1: n + 2
I think this is the result of debugging being implemented by setting
a flag in the environment of the function being debugged. That's how
the debug status gets passed on to inner statements. Your {n+2}
expression looks like an inner statement, and of course has the
environment of the call of Fun. (In contrast, (n+2) doesn't do this,
because "(" doesn't check for debugging.)
You could avoid it with some hack like using (function(){n+2})()
rather than {n+2}. (I'm assuming there's some reason you're not
just using (n+2), with parentheses rather than curly brackets).
I've considered changing how this works in pqR, using pqR's "variant
return" mechanism to pass on the information that an inner statement
should be debugged. This would also allow one to avoid entering the
debugger for "if" when it is used as an expression rather than a
statement (for example, a <- if (x>0) 3 else 4).
Radford Neal