[Rd] Problem with hasArg and the ... argument (PR#7027)
p.dalgaard at biostat.ku.dk
Tue Jun 29 17:21:02 CEST 2004
John Chambers <jmc at research.bell-labs.com> 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
> 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.
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
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
More information about the R-devel