2

I understand how to use ellipses when I only want one function to receive those arguments:

ok <- function(x, ...){
    sum(x, ...)
}
x.in <- c(1:9, NA)
ok(x.in, na.rm=TRUE)

I start getting confused when some functions need only certain parts of .... I was thinking of using something like names(formals(cor)) to test for which arguments in ... to send where, but I don't see how to do this for sum or plot. In general, I want to write functions similar to the following:

yikes <- function(x, ...){
    plot(x, ...)
    sum(x, ...) + cor(x, ...)
}
x.in <- c(1:9, NA)
x.in.jitter <- jitter(x.in)
yikes(x.in, y=x.in.jitter, na.rm=TRUE, use="na.or.complete", type="o")

Ideally, yikes() would do the following:

plot(x=x.in, y=x.in.jitter, type="o")
sum(x.in, na.rm=TRUE) + cor(x=x.in, y=x.in.jitter, use="na.or.complete")

I suspect part of the solution may use match.call. How would I get a function like yikes() to work? Is this simply a bad idea?

Edit: The second link in the first comment goes a long way to answering this question given the situation where you know/ are willing to explicitly describe what parameters get passed to what functions. Using the arguments of functions called directly (e.g., cor, plot, sum in yikes), or indirectly (par via plot) to indicate what arguments supplied via ... should be used for a particular function is what I am searching for. I understand the case for cor, e.g.; but how would one do this for plot, without explicitly mentioning par or the arguments it takes?

rbatt
  • 4,677
  • 4
  • 23
  • 41
  • [this](http://stackoverflow.com/questions/16774946/passing-along-ellipsis-arguments-to-two-different-functions) and [this](http://stackoverflow.com/questions/4124900/is-there-a-way-to-use-two-statements-in-a-function-in-r) might help. – Pierre L Jun 27 '15 at 00:27
  • @plafort thanks for those links, but does that suggest I need to know what function the `...` goes to (`plot` goes to `par`, e.g.)? Also, does that handle the issue with `sum()` getting the `type="o"` argument? Based on the answers in those questions, I have a feeling that there is not a simple and elegant answer for these cases. – rbatt Jun 27 '15 at 00:37
  • The second answer addresses the problem you will have if you pass `...` to `cor` and the dots have an `na.rm` argument in them. You need to study that answer more carefully. – IRTFM Jun 27 '15 at 00:52
  • After studying some more, it still seems like something along the lines of `c(names(formals(plot.default)), names(par()))` is required (for plot, e.g.). I'm thinking that in my example, dealing with `sum` is impossible, because anything could go there (nothing to match to). But say you couldn't know that `plot` was sending the `...` to `par`, what then? Is there a way to drill down further with `formals`, applying recursively to any function `plot` (e.g.) sends its `...` to? I get `cor`, that's easy b/c `formals(cor)` shows all (as I mention in my Q) – rbatt Jun 27 '15 at 01:15
  • 1
    No, it's not a bad idea. However, the ellipse lacks clarity in that case. Instead, you can work with separate arguments, e.g., `plot.args`, `sum.args` etc., each of which may be a list containing the additional arguments. Inside the function, you can call the other functions using `do.call` while referring to the function-specific list of additional arguments. – SimonG Jun 27 '15 at 10:19

0 Answers0