[Rd] Problem with hasArg and the ... argument (PR#7027)

[Peter Dalgaard]

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
> 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
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907