3 ms·

I'm not sure this is right; the NSE stuff tends to be at the shell, the user-facing API. The workhorse functions generally are referentially transparent, and wr

I'm not sure this is right; the NSE stuff tends to be at the shell, the user-facing API. The workhorse functions generally are referentially transparent, and writing pure functions is both natural and recommended in R. The slow parts are deeper than the NSE, so removing NSE wouldn't open up much room to optimize. I suspect pass-by-value is a much bigger barrier to speed in R than non-standard evaluation.

ChrisRackauckas 8y ago
Oh yes, I forgot about its pass-by-value. Removing pass-by-value is a double edged sword though. I generally dislike it, but you have to admit that having everything pass-by-value is much simpler to a non-programmer. If you chop that out then the "fast R subset" suddenly can act very differently. In order to really write efficient code you'd want to start making use of mutation on this fast part. This means throwing a macro on some array-based R code won't really be automatic: it would need a bit of a re-write for full speed but the re-written version would be incompatible with pass-by-value semantics. This is quite an interesting and tough problem to solve. I think it might be better to keep things pass-by-value and try to optimize pure functions.
nerdponx 8y ago
What about copy-on-write semantics? Or is that not a big deal (since you can just "not do it").