I have no particular example in mind, though if your data are in lists (e.g. data frames) or better yet you want to add new data to a list then a particular trap for inexperienced analysts is trying to capture the name of the not-yet-created item from a symbol instead of simply giving the function a string to label the new item with.
I must say playing around with ... seems tediously unpleasant to me... to each their own though. I prefer to let R handle that... if I want to tweak a variable being passed I just declare the parameter explicitly and pass it along explicitly. As long as it has a default value the calling function shouldn't care... unless it is also abusing .... On January 6, 2025 5:15:59 PM PST, Bert Gunter <bgunter.4...@gmail.com> wrote: >Jeff: >Would you care to offer an example of: > >"String literals are surprisingly simple alternatives that don't bite you >in the butt nearly so often as NSE does." > >"No" is a perfectly acceptable answer. > >I would generally agree with you about NSE, but my original query was >motivated by something simple. I like to use lattice graphics when I fool >around with graphing data, as I'm retired and don't have to worry about >adhering to organizational or journal standards built around the ggplot >graphics grammar or require it's very extensive and sophisticated >capabilities. But I do often create custom panel displays, which typically >requires that I have to pass around long default lists of graphics >arguments via "..." that I modify to suit my aesthetic and analytical >preferences. Ergo my query about how to check what's in the "..." list >without requiring evaluation, which Iris helped me with. > >I would also suggest that as a personal user of R for "data science stuff", >one can avoid a lot of the complexities to which you allude; while as a >developer of "tools" (chiefly packages) for others, one has to wade into a >lot of those complexities. This is just a software cliché I think. >Unfortunately, S and therefore R, were originally designed for a pretty >sophisticated audience (ATT labs researchers) and intentionally, and to me >rather seductively, blurred the line between "user" and "developer." All >IMO, of course. YMMV. > >Cheers, >Bert > > >On Mon, Jan 6, 2025 at 4:04 PM Jeff Newmiller <jdnew...@dcn.davis.ca.us> >wrote: > >> It is a pretty tricky topic, but IMO Advanced R [1] steps you through it >> systematically... you just have to be prepared to follow along in R with >> the examples as you read it. In particular, the chapter on Functions goes >> through this. >> >> The subtleties of how base R gives you control over these topics is what >> lead to the tidyverse creating new packages to build such function >> interfaces. Manipulating object evaluation from arbitrary environments is >> still complex, and the more you learn about it the more you learn to avoid >> it for certain types of tasks. String literals are surprisingly simple >> alternatives that don't bite you in the butt nearly so often as NSE does. >> >> [1] https://adv-r.hadley.nz/ >> >> On January 6, 2025 3:26:25 PM PST, "Sorkin, John" < >> jsor...@som.umaryland.edu> wrote: >> >Bert and other on this Chain, >> > >> >The original question asked by Bert Gunter, highlights one of my long >> standing wishes. Perhaps my wish has already been fulfilled (if it has, >> please let me know where I can look of fulfill my wish), if it hasn't >> perhaps someone can grant me my wish. >> > >> >I have tried to understand how to write a function (beyond a basic >> function), get values of the parameters, and process the parameters. I have >> looked for a source that clearly describes how his may be done (with >> examples), but I have yet to find one. Yes, one can look at a function >> (e.g. lm) look at the statements that are used and use the help system to >> research each of the statements (I have done this), but doing this is not >> the most efficient way to learn the topic. It would be very helpful if >> someone Knowledgeable would put together a primer on writing functions and >> processing function arguments. If such a document exist, I would be happy >> to have someone send me its URL. >> > >> >Thank you, >> >John >> > >> >John David Sorkin M.D., Ph.D. >> >Professor of Medicine, University of Maryland School of Medicine; >> >Associate Director for Biostatistics and Informatics, Baltimore VA >> Medical Center Geriatrics Research, Education, and Clinical Center; >> >PI Biostatistics and Informatics Core, University of Maryland School of >> Medicine Claude D. Pepper Older Americans Independence Center; >> >Senior Statistician University of Maryland Center for Vascular Research; >> > >> >Division of Gerontology and Paliative Care, >> >10 North Greene Street >> >GRECC (BT/18/GR) >> >Baltimore, MD 21201-1524 >> >Cell phone 443-418-5382 >> > >> > >> > >> > >> >________________________________________ >> >From: R-help <r-help-boun...@r-project.org> on behalf of Bert Gunter < >> bgunter.4...@gmail.com> >> >Sent: Monday, January 6, 2025 5:22 PM >> >To: Jorgen Harmse >> >Cc: r-help@r-project.org >> >Subject: Re: [R] Extracting specific arguments from "..." >> > >> >Thanks Jorgen. >> > >> >I thought your approach to getting the argument expressions was clever, >> but >> >somewhat convoluted. I think the usual simple way is to use match.call() >> >(or sys.call() )to get the unevaluated argument expressions; e.g. ... >> > >> >f <- function(...){ >> > match.call() >> >} >> >> f(a = 'red', b = sin(zzz)) >> >f(a = "red", b = sin(zzz)) >> > >> >The return value is an object of class call that can be subscripted as (or >> >converted by as.list() to) a list to extract the argument expressions: >> >> f(a = 'red', b = sin(zzz))$b >> >sin(zzz) >> > >> >You'll note that the $b component is again of class "call". So you may >> wish >> >to convert it to character or expression or whatever for further >> >processing, depending on context. Obviously, I haven't thought about this >> >carefully. >> > >> >You raise an important point about robustness. I believe this approach to >> >extracting the call expressions should be fairly robust, but I do get >> >confused about the lay of the land when you add promises with default >> >arguments that may not yet have been forced before match.call() is called. >> >You may have to wrestle with sys.call() and it's "wh" argument to make >> >things work the way you want in that situation. I leave such delights to >> >wiser heads, as well as any corrections or refinements to anything that >> >I've said here. >> > >> >Cheers, >> >Bert >> > >> >On Mon, Jan 6, 2025 at 9:55 AM Jorgen Harmse <jhar...@roku.com> wrote: >> > >> >> I think Bert Gunter is right, but do you want partial matches (not found >> >> by match), and how robust do you want the code to be? >> >> >> >> >> >> >> >> f <- function(…) >> >> >> >> { pos <- match('a', ...names()) >> >> >> >> if (is.na(pos)) >> >> >> >> stop("a is required.") >> >> >> >> …elt(pos) >> >> >> >> } >> >> >> >> >> >> >> >> Incidentally, what is the best way to extract the expression without >> >> evaluating it? >> >> >> >> >> >> >> >> g <- function(...) >> >> >> >> { pos <- match('a',...names()) >> >> >> >> if (is.na(pos)) >> >> >> >> stop("a is missing.") >> >> >> >> (function(a,...) substitute(a)) (...) >> >> >> >> } >> >> >> >> >> >> >> >> Regards, >> >> >> >> Jorgen Harmse. >> >> >> >> >> >> >> >> Message: 8 >> >> Date: Sun, 5 Jan 2025 11:17:02 -0800 >> >> From: Bert Gunter <bgunter.4...@gmail.com> >> >> To: Iris Simmons <ikwsi...@gmail.com> >> >> Cc: R-help <R-help@r-project.org> >> >> Subject: Re: [R] Extracting specific arguments from "..." >> >> Message-ID: >> >> < >> >> cagxfjbronopt-bodf6srpp79bwucppoo3+ycdgn3y-ytdu5...@mail.gmail.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Thanks, Iris. >> >> That is what I suspected, but it wasn't clear to me from the docs. >> >> >> >> Best, >> >> Bert >> >> >> >> On Sun, Jan 5, 2025 at 10:16 AM Iris Simmons <ikwsi...@gmail.com> >> wrote: >> >> > >> >> > I would use two because it does not force the evaluation of the other >> >> arguments in the ... list. >> >> > >> >> > >> >> > >> >> > On Sun, Jan 5, 2025, 13:00 Bert Gunter <bgunter.4...@gmail.com> >> wrote: >> >> >> >> >> >> Consider: >> >> >> >> >> >> f1 <- function(...){ >> >> >> one <- list(...)[['a']] >> >> >> two <- ...elt(match('a', ...names())) >> >> >> c(one, two) >> >> >> } >> >> >> ## Here "..." is an argument list with "a" somewhere in it, but in an >> >> >> unknown position. >> >> >> >> >> >> > f1(b=5, a = 2, c=7) >> >> >> [1] 2 2 >> >> >> >> >> >> Which is better for extracting a specific named argument, one<- or >> >> >> two<- ? Or a third alternative that is better than both? >> >> >> Comments and critiques welcome. >> >> >> >> >> >> Cheers, >> >> >> Bert >> >> >> >> >> >> ______________________________________________ >> >> >> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> >> >> https://stat.ethz.ch/mailman/listinfo/r-help >> >> >> PLEASE do read the posting guide >> >> https://www.r-project.org/posting-guide.html >> >> >> and provide commented, minimal, self-contained, reproducible code. >> >> >> >> >> >> >> >> >> > >> > [[alternative HTML version deleted]] >> > >> >______________________________________________ >> >R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> >https://stat.ethz.ch/mailman/listinfo/r-help >> >PLEASE do read the posting guide >> https://www.r-project.org/posting-guide.html >> >and provide commented, minimal, self-contained, reproducible code. >> >______________________________________________ >> >R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> >https://stat.ethz.ch/mailman/listinfo/r-help >> >PLEASE do read the posting guide >> https://www.R-project.org/posting-guide.html >> >and provide commented, minimal, self-contained, reproducible code. >> >> -- >> Sent from my phone. Please excuse my brevity. >> -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide https://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
