I was thrilled to see this in the change log:> match.call() gains an envir argument for specifying the environment from
which to retrieve the ... in the call, if any; this environment was wrong (or at
least undesirable) when the definition argument was a function.
This was an issue I ran into a few years ago.? I ended up writing my own version
that allows specification of the environment, but being able to rely on the
built in R version seems much better.? That said, one issue remains as far as I
can tell: if the `...` values are expressions they are substituted by `..1`,
`..2`, etc.? For example:> fun0 <- function(...) {
>?? fun_gpar <- function(b, ...) {
>???? fun_par <- function(a)
>?????? match.call(fun_gpar, sys.call(sys.parent()), envir=parent.frame(2L))
>???? fun_par()
>?? }
>?? fun_gpar(...)
> }
> fun0(999, 2 + 2, 3 * pi(), 4)
Returns:> fun_gpar(b = 999, ..2, ..3, 4)
Instead of:
> fun_gpar(b = 999, 2 + 2, 3 * pi(), 4)
This is better than what used to happen before we had access to the `envir`
parameter:
> fun_gpar(b = ..1, ..2, 4)
The dot substitution happens in `subDots` in `main/src/unique.c at 1228` (in
3.2.2 sources available as of today in CRAN).? Here is a snippet from that
function:>??? for(a = dots, b = rval, i = 1; i <= len; a = CDR(a), b = CDR(b), i++)
{
>??? ??? SET_TAG(b, TAG(a));
>??? ??? t = CAR(a);
>??? ??? while (TYPEOF(t) == PROMSXP)
>??? ??? ??? t = PREXPR(t);
>??? ??? if( isSymbol(t) || isLanguage(t) )
>??? ??? ??? SETCAR(b, installDDVAL(i));?? // <-- HERE
>??? ??? else
>??? ??? ??? SETCAR(b, t);
>??? }
The `installDDVAL(i)` generates the `..X` symbols.? I'm sure there is a very
good reason why this is done, but then it does lead to the issues above.
Am I just doing something wrong?
My workaround (https://github.com/brodieG/matchcall) addresses both the `..X`
issue as well as the environment issue, but I'd prefer to deprecate it in
favor of a base R solution if possible.
B.
[[alternative HTML version deleted]]