John Chambers <[EMAIL PROTECTED]> writes: > > and sys.function is documented with argument 'n', which we'd have to > > change to 'which', but the default is n=0 for "current function" which > > is unlike 'which' which has 0 meaning .GlobalEnv. Argh... > > > > My take is that we need to fix sys.function to behave according to > > docs, change what we can in the R internals, and face the consequences > > for package maintainers. > > Things are actually messier, even. > > 1. A counter-argument for changing the documentation might be that the > green book (p 106) and S-Plus take the argument to be the frame number > (only sys.parent(n) uses the argument for the number of frames back). > > Unfortunately for the counter-argument, the (current) R implementation > and the S-Plus implementation differ in where they start indexing. In > S-Plus, 1 is the top-level frame (corresponding to the global > environment). In R, it is the first function call frame (and 0 > corresponds to the global environment). > > So there seems no way to have R/S-Plus compatibility. > > 2. And R-only consistency does not look too good either: sys.call() and > sys.frame() claim to have the which= behavior. It's not very natural > for sys.function() to behave differently. > > And even if that didn't bother us, sys.call(0) returns the current call, > not the "global call" (whatever that would mean), regardless of > documentation. (The test at the bottom of this mail illustrates.) > > What to do? Well, a tentative suggestion. > - Leave the implementation almost alone--no simple fix will clean up all > the problems. Optionally make one change: If sys.frame(0) produced the > frame of the current call, then sys.function, sys.call, and sys.frame > would be consistent. > > - Change the documentation to give sys.function argument `which', > explaining that which=0 is interpreted as the current > call/function/frame. > > If we wanted to leave the implementation totally unchanged, then we have > to admit the inconsistency in sys.frame, and tell people to use > sys.frame(sys.nframe()) to produce the current frame.
(or environment()!) Changing the behaviour of sys.frame() would probably mess rather badly with the sys.frame(sys.parent()) idiom whenever sys.parent() returns zero (yes I know about parent.frame(), but does everybody else?). Probably, we should just document what we got, possibly changing the argument name in sys.function() from n to which. I think we might be able to explain succinctly that sys.call(0) and sys.function(0) gives current call and function, since there is no "top level" definitions of the two. -- O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
