[R] Recovering object names when using the ... argument in a fn XXXX

William Dunlap wdunlap at tibco.com
Mon Oct 21 21:13:41 CEST 2013


> Just curious, does substitute(...()) buy you anything that you don't get from the
> straightforward
> 
> match.call(expand.dots=FALSE)$...

substitute() makes is easier to bury the idiom in a function so you don't have to
remember the weird syntax.
   > dotdotdot1 <- function(...)substitute(...())
   > dotdotdot2 <- function(...)match.call(expand.dots=FALSE)$...
   > (function(..., FUN)dotdotdot1(...))(1:10, onProblem=stop("oops"), FUN=objects)
   [[1]]
   1:10
   
   $onProblem
   stop("oops")

   > (function(..., FUN)dotdotdot2(...))(1:10, onProblem=stop("oops"), FUN=objects)
   [[1]]
   ..1
   
   $onProblem
   ..2

I suppose one could figure out appropriate values for match.call's 'definition'
and 'call' arguments to make this work.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com


> -----Original Message-----
> From: peter dalgaard [mailto:pdalgd at gmail.com]
> Sent: Monday, October 21, 2013 11:56 AM
> To: Duncan Murdoch
> Cc: Bert Gunter; William Dunlap; r-help at r-project.org
> Subject: Re: [R] Recovering object names when using the ... argument in a fn XXXX
> 
> 
> On Oct 19, 2013, at 19:03 , Duncan Murdoch wrote:
> 
> > On 13-10-18 1:54 PM, Bert Gunter wrote:
> >> Yes, similar, but better, as match.call() will get unwanted named
> >> arguments, too.
> >>
> >> However, I do not understand the
> >>
> >> substitute(...())
> >>
> >> idiom. Would you care to explain it? (No is an acceptable  answer!).
> >
> > I suspect it's a bug, though I can't see it's one that's likely to need fixing.  The general
> idea is that a function call like ...() is parsed into a pairlist containing just the name "...",
> then substitute replaces it with the content of that variable, which is a pairlist containing
> the unevaluated argument list.  So by that analysis, you might expect to get the same
> result using
> >
> > pairlist(...)
> >
> > However, you don't, because the latter expression evaluates all the arguments to the
> function, while Bill's idiom leaves them unevaluated. I can't think of any documented
> reason why that should be, but on the other hand, I can't think of any reason it would
> cause problems.  So I'd say it's unlikely to be deliberately changed, but it might change as
> a result of some internal change to R.
> >
> > Duncan Murdoch
> >
> 
> Just curious, does substitute(...()) buy you anything that you don't get from the
> straightforward
> 
> match.call(expand.dots=FALSE)$...
> 
> ???
> -pd
> 
> 
> >
> >>
> >> I would have expressed it as:
> >>
> >> as.list(substitute(list(...)))[-1]
> >>
> >> to convert the parse tree to a list. (which is again better than using
> >> match.call() ).
> >>
> >> Best,
> >> Bert
> >>
> >> On Fri, Oct 18, 2013 at 10:27 AM, William Dunlap <wdunlap at tibco.com> wrote:
> >>>> I am using the ... argument to parmeterize a user define fn to accept
> >>>> multiple input objects. I subsquently save all these data as a list.
> >>>> Question: what is the best way to recover or extract the original object
> >>>> names that were fed to the fn?
> >>>
> >>> The following function, ellipsisInfo, returns character strings representing the
> >>> actual arguments to the function.  If the function was called with tags on the
> >>> arguments, as in ellipsisInfo(tag=argument), it makes those tags the names
> >>> on the returned character  vector.  It does not evaluate the ... arguments, so
> >>> you don't run into problems with evaluating arguments too soon or evaluating
> >>> ones that should not be evaluated most of the time.
> >>>
> >>> ellipsisInfo <- function(...) {
> >>>     # get the unevaluated expressions given as arguments
> >>>     unevaluatedArgs <- substitute(...())
> >>>     # convert those expressions to text (truncate to single line)
> >>>     unevaluatedArgsAsText <- vapply(unevaluatedArgs, function(a)deparse(a)[1], "")
> >>>     unevaluatedArgsAsText
> >>> }
> >>>
> >>> E.g.,
> >>>
> >>>> i <- ellipsisInfo(x, log(10), e=exp(1), onProblem=stop("there was a problem"))
> >>>> i
> >>>
> >>>                             "x"
> >>>
> >>>                       "log(10)"
> >>>                               e
> >>>                        "exp(1)"
> >>>                       onProblem
> >>> "stop(\"there was a problem\")"
> >>>> ifelse(names(i)=="", i, names(i)) # use tag if supplied, otherwise argument itself
> >>> [1] "x"         "log(10)"   "e"
> >>> [4] "onProblem"
> >>>
> >>> Bill Dunlap
> >>> Spotfire, TIBCO Software
> >>> wdunlap tibco.com
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] On
> Behalf
> >>>> Of Dan Abner
> >>>> Sent: Friday, October 18, 2013 9:06 AM
> >>>> To: r-help at r-project.org
> >>>> Subject: [R] Recovering object names when using the ... argument in a fn XXXX
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I am using the ... argument to parmeterize a user define fn to accept
> >>>> multiple input objects. I subsquently save all these data as a list.
> >>>> Question: what is the best way to recover or extract the original object
> >>>> names that were fed to the fn?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Dan
> >>>>
> >>>>       [[alternative HTML version deleted]]
> >>>>
> >>>> ______________________________________________
> >>>> R-help at r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-help
> >>>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> >>>> and provide commented, minimal, self-contained, reproducible code.
> >>>
> >>> ______________________________________________
> >>> R-help at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-help
> >>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> >>> and provide commented, minimal, self-contained, reproducible code.
> >>
> >>
> >>
> >
> > ______________________________________________
> > R-help at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-help
> > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> > and provide commented, minimal, self-contained, reproducible code.
> 
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com
> 
> 
> 
> 
> 
> 
> 



More information about the R-help mailing list