3 ms·
I don't know if this is a _general_ downside of NSE, but in the specific context of dplyr, I've found that the focus on NSE has made it a pain to do things in a
by claytonjy 10y ago
I don't know if this is a _general_ downside of NSE, but in the specific context of dplyr, I've found that the focus on NSE has made it a pain to do things in a standard-evaluation way, like if you're writing general functions that use dplyr under the hood.
Dplyr provides SE versions for most all functions, but you frequently need `lazyeval::interp` when building expressions that do work (e.g. for `mutate_`): https://cran.r-project.org/web/packages/dplyr/vignettes/nse.html https://cran.r-project.org/web/packages/dplyr/vignettes/nse....
Notice that document avoids full examples of se-dplyr + lazyeval; I suspect this is purposeful because it tends to look horrid compared to the usual NSE approach. That said, dplyr is still an amazingly productive paradigm shift and I'll keep using it.
- rcthompson 10y agoYes, they're isn't really any dedicated syntax in R for manipulating unevaluated expressions, which makes it difficult to write comprehensible metaprogramming code.