Tukukkk

This is how I have been thinking that ellipsis works in nested functions: when you hand a set of arguments to a function via ellipsis, any function subsidiary to it on the call stack can get at those arguments -- I thought, via its own ellipsis. I have believed that arguments passed to ellipsis cumulate, so that the inmost ellipsis contains all the arguments passed through ellipsis arguments in any of the functions superior to it in the call stack.

But I just did an experiment to confirm this, and it now appears to me to be wrong. Thus:

> f02 <- function(...){

+   vv <- list(...)

+   print(vv)

+ }

> f01 <- function(...){

+   f02(b = 2)

+ }

> f01(a=1)

$`b`

[1] 2

Here the inner ellipsis does not seem to have inherited the a=1 argument from the outer ellipsis.

So my current theory is that when you take an action that asks for the contents of …, such as list(…), match.call(expand.dots=TRUE), or as.list(substitute(list(...)))[-1], you only get the first instance of … that is encountered, based on the search path under normal scoping rules. But I have to say, this seems unlikely to me. If it were true, then, e.g., graphical parameters supplied to a plotting function several calls down would suffer mysterious failures if one of the intervening functions had a … argument.

So I am wondering if there are some special rules for scoping arguments sought in dot-dot-dots, such as looking for a superior instance if the local one is empty, or if you look in … for a particular named argument, say list(...)$my_parameter, and do not find it there . Neither of these solutions strikes me as very plausible, but, well, none of the ones I have come up with do.

Previous questions on this topic seem to be focused mainly on various edge cases. I'm looking more for understanding the passing rules in the normal case (but possibly with multiple layers of calls).

Ellipsis has to be explicitly provided to pass to a nested function, so for example, in your f02, the list call gets whatever was passed to f02 as its own arguments. In contrast, in f01, the arguments are simply ignored. You could pass the arguments to f02 within f01 thus:

  f01 <- function(...){

  f02(b = 2,...)

}

Result:

f01(a=1)

$b

[1] 2



$a

[1] 1

This works regardless of the number of arguments in the ellipsis:

f01(a=1,c=3)

$b

[1] 2



$a

[1] 1



$c

[1] 3

I'm hoping that the forum lets me post an answer and still accept iod's answer. This is my intent.

It appears that my original belief -- that the dots cumulate all the arguments supplied to them along the call stack -- is true provided that ellipsis (...) are included in both the function definitions and the function calls for all the calls subsidiary to the first. See the code below. To me this suggests that a ... argument should routinely be added to function calls embedded inside other functions, if there is any possibility that subsidiary functions somewhere down the chain may need an argument supplied at the top level which can not be identified and passed explicitly when the function is written. If someone reading this has a good reason to believe this is a bad idea, I'd like to hear about it.

Note that although ellipsis are required in the calls to functions 2 and 3 in order to pass their arguments inward, it is forbidden at the top level, resulting in a '...' used in an incorrect context error. I find this puzzling. I would have expected a '...' not found error, given that the dots are allowed in the subsidiary calls.

In addition, I don't understand why the name of the third argument is reported as `c`. It is not because c is a function name; the same thing happens with c1.

> f03 <- function(...){

+   vv <- list(...)

+   print(vv)

+ }

> f02 <- function(...){

+   f03(c = 3, ...)

+ }

> f01 <- function(...){

+   f02(b = 2, ...)

+ }

> f01(a = 1)

$`c`

[1] 3



$b

[1] 2



$a

[1] 1