> However, I do not understand the > substitute(...()) > idiom. Would you care to explain it? (No is an acceptable answer!).
I don't completely understand it either, I treat it as an idiom. I saw it on this list once. Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > -----Original Message----- > From: Bert Gunter [mailto:gunter.ber...@gene.com] > Sent: Friday, October 18, 2013 10:54 AM > To: William Dunlap > Cc: Dan Abner; r-help@r-project.org > Subject: Re: [R] Recovering object names when using the ... argument in a fn > XXXX > > 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 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 <wdun...@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-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On > Behalf > >> Of Dan Abner > >> Sent: Friday, October 18, 2013 9:06 AM > >> To: r-help@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@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@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. > > > > -- > > Bert Gunter > Genentech Nonclinical Biostatistics > > (650) 467-7374 ______________________________________________ R-help@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.
