3 ms·

You can use functions in R because R is a crazy language that lets functions access the expressions which are passed as parameters and not just the values of th

You can use functions in R because R is a crazy language that lets functions access the expressions which are passed as parameters and not just the values of the arguments.

blahi 10y ago
Non-standard evaluation is one of the best features of R.
cwyers 10y ago
You mean like this? http://adv-r.had.co.nz/Computing-on-the-language.html#nse http://adv-r.had.co.nz/Computing-on-the-language.html#nse So, this use-case would seem to point out one advantage of being a "crazy language" in this case. What are the downsides of NSE?
- baldfat 10y ago
  Most people don't know that R has a OO and a Functional side to it. After I learned Racket my R programming changed. After hunting down why I found out that the authors of R wanted to add scheme into the S language when they created R. So you can do some very functional style writing that looks very elegant.
- one-more-minute 10y ago
  It's a cool feature which enables some really nice APIs, but it also has the potential to break your mental model when reading code. For example: x <- f(a) y <- g(x, z) vs y <- g(f(a), z) It would be extremely unexpected if the result `y` was different for these two expressions, but you can't know for sure without reading `f` – since it could be using NSE. This applies to any innocent-looking function in any library you use – imagine trying to debug an issue caused by something like this. It's also awful for performance. Allowing functions to peek at their arguments at any time is one of the things that makes R virtually impossible to optimise effectively. Of course, libraries like dplyr also show that it can be used to great effect in the right hands.
  - GlennS 10y ago
    I think this is a big part of why R is such a success amongst data analysts. A lot of R libraries have a really good human interface which you can play around with and it will successfully DWIM a lot of the time. Once you start trying to drive R in a more automatic way with your own programs, though, it starts to get really messy. I wouldn't want to make even a medium-sized program in it (10,000 lines would be too, for example). Then it's time to switch to Python with numpy. I wonder if Julia will be able to cover both types of program effectively. There's definitely a niche for it if it can.
- 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 ago
    Yes, they're isn't really any dedicated syntax in R for manipulating unevaluated expressions, which makes it difficult to write comprehensible metaprogramming code.
nerdponx 10y ago
Isn't this a feature of Lisp-alikes in general?
- rcthompson 10y ago
  In most lisp-like languages, there is a distinction between functions (standard evaluation) and macros (non-standard evaluation). A given callable is either one or the other. In R, every function is both, since it can access both the evaluated and unevaluated forms of each of its arguments.

You can use functions in R because R is a crazy language that lets functions access the expressions which are passed as parameters and not just the values of the arguments.

blahi 10y ago

Non-standard evaluation is one of the best features of R.

cwyers 10y ago

You mean like this? http://adv-r.had.co.nz/Computing-on-the-language.html#nse http://adv-r.had.co.nz/Computing-on-the-language.html#nse So, this use-case would seem to point out one advantage of being a "crazy language" in this case. What are the downsides of NSE?

baldfat 10y ago
Most people don't know that R has a OO and a Functional side to it. After I learned Racket my R programming changed. After hunting down why I found out that the authors of R wanted to add scheme into the S language when they created R. So you can do some very functional style writing that looks very elegant.
one-more-minute 10y ago
It's a cool feature which enables some really nice APIs, but it also has the potential to break your mental model when reading code. For example: x <- f(a) y <- g(x, z) vs y <- g(f(a), z) It would be extremely unexpected if the result `y` was different for these two expressions, but you can't know for sure without reading `f` – since it could be using NSE. This applies to any innocent-looking function in any library you use – imagine trying to debug an issue caused by something like this. It's also awful for performance. Allowing functions to peek at their arguments at any time is one of the things that makes R virtually impossible to optimise effectively. Of course, libraries like dplyr also show that it can be used to great effect in the right hands.
- GlennS 10y ago
  I think this is a big part of why R is such a success amongst data analysts. A lot of R libraries have a really good human interface which you can play around with and it will successfully DWIM a lot of the time. Once you start trying to drive R in a more automatic way with your own programs, though, it starts to get really messy. I wouldn't want to make even a medium-sized program in it (10,000 lines would be too, for example). Then it's time to switch to Python with numpy. I wonder if Julia will be able to cover both types of program effectively. There's definitely a niche for it if it can.
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 ago
  Yes, they're isn't really any dedicated syntax in R for manipulating unevaluated expressions, which makes it difficult to write comprehensible metaprogramming code.

nerdponx 10y ago

Isn't this a feature of Lisp-alikes in general?

rcthompson 10y ago
In most lisp-like languages, there is a distinction between functions (standard evaluation) and macros (non-standard evaluation). A given callable is either one or the other. In R, every function is both, since it can access both the evaluated and unevaluated forms of each of its arguments.