I would like to once again recommend our readers to our note on
R function that can help you eliminate many problematic NSE (non-standard evaluation) interfaces (and their associate problems) from your
R programming tasks.
The idea is to imitate the following lambda-calculus idea:
let x be y in z := ( λ x . z ) y
Continue reading wrapr::let()
wrapr 1.4.1 is now available on CRAN.
wrapr is a really neat
R package both organizing, meta-programming, and debugging R code. This update generalizes the dot-pipe feature’s dot S3 features.
Please give it a try!
Continue reading wrapr 1.4.1 now up on CRAN
Another R tip. Need to replace a name in some R code or make R code re-usable? Use
Continue reading R Tip: Use let() to Re-Map Names
I would like to demonstrate some helpful
R notation tools that really neaten up your
Img: Christopher Ziemnowicz.
Continue reading Supercharge your R code with wrapr
Our article "Let’s Have Some Sympathy For The Part-time R User" includes two points:
- Sometimes you have to write parameterized or re-usable code.
- The methods for doing this should be easy and legible.
The first point feels abstract, until you find yourself wanting to re-use code on new projects. As for the second point: I feel the
wrapr package is the easiest, safest, most consistent, and most legible way to achieve maintainable code re-use in
In this article we will show how
wrapr makes code-rewriting even easier with its new
let x=x automation.
Continue reading Let X=X in R
Saw this the other day:
In defense of
wrapr::let() (originally part of
replyr, and still re-exported by that package) I would say:
let() was deliberately designed for a single real-world use case: working with data when you don’t know the column names when you are writing the code (i.e., the column names will come later in a variable). We can re-phrase that as: there is deliberately less to learn as
let() is adapted to a need (instead of one having to adapt to
R community already has months of experience confirming
let() working reliably in production while interacting with a number of different packages.
let() will continue to be a very specific, consistent, reliable, and relevant tool even after
dpyr 0.6.* is released, and the community gains experience with
tidyeval in production.
tidyeval is your thing, by all means please use and teach it. But please continue to consider also using
wrapr::let(). If you are trying to get something done quickly, or trying to share work with others: a “deeper theory” may not be the best choice.
An example follows. Continue reading In defense of wrapr::let()