DataTaunew | comments | leaders | submitlogin
1 point by jmount 2700 days ago | link | parent

replyr::let is based (with attribution) on gtools::strmacro. It sets up a useful macro replacement of names to names (not values, so it has somewhat different semantics than base::substitute, such as being able to re-write both left hand sides and right hand sizes of dplyr::mutate assignments).

The code in the let block can be arbitrarily large (so eventually the relative cost of the boilerplate goes down). help(let) has some more detailed examples including piping through a let block.

This is based in my earlier extensions to dplyr proposal, but is separate in that it is a stand-alone functioning work around.

Nina also demonstrates replyr::let with ggplot2 in vignette('letExample','replyr'). We also have overall documentation in vignette('replyr','replyr').

replyr tries to be "dplyr pure." If you write "pure dplyr code" (that is code that works on any dplyr back-end, i.e. avoiding d$column or d[['column']] in favor of "d %>% select(column)" then the combined code should also work with many dplyr data services (we test with tbl, SQLite, MySQL, PostgreSQL, sparklyr/Spark1.6.2, sparklyr/Spark2.0.2), assuming you only use functions available on the service in question (which varies a lot for window functions like cumsum and functions like median).

Nina has an additional "why you should care" article here: https://ninazumel.com/2016/12/06/new-win-vector-package-repl... . We are not against lazyeval, just against the end user having to directly call lazyeval without any helpers/wrappers.




RSS | Announcements