[Rd] suggestion: "." in [lsv]apply()

Sokol Serguei @oko| @end|ng |rom |n@@-tou|ou@e@|r
Thu Apr 16 17:53:07 CEST 2020


Thanks for replying. In what follows I won't try to argue (I understood 
that you find this a bad idea) but I would like to make clearer some of 
your point for me (and may be for others).

Le 16/04/2020 à 16:48, Simon Urbanek a écrit :
> Serguei,
>> On 17/04/2020, at 2:24 AM, Sokol Serguei <sokol using insa-toulouse.fr> 
>> wrote: Hi, I would like to make a suggestion for a small syntactic 
>> modification of FUN argument in the family of functions [lsv]apply(). 
>> The idea is to allow one-liner expressions without typing 
>> "function(item) {...}" to surround them. The argument to the 
>> anonymous function is simply referred as ".". Let take an example. 
>> With this new feature, the following call sapply(split(mtcars, 
>> mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared) # 4 6 8 
>> #0.5086326 0.4645102 0.4229655 could be rewritten as 
>> sapply(split(mtcars, mtcars$cyl), summary(lm(mpg ~ wt, .))$r.squared) 
>> "Not a big saving in typing" you can say but multiplied by the number 
>> of [lsv]apply usage and a neater look, I think, the idea merits to be 
>> considered. 
> It's not in any way "neater", not only is it less readable, it's just 
> plain wrong. What if the expression returned a function?
do you mean like in
l=sapply(1:3, function(i) function(x) i+x)
# 4
# 5

This is indeed a corner case but a pair of () or {} can keep wsapply() 
in course:
l=wsapply(1:3, (function(x) .+x))


# 4


# 5
> How do you know that you don't want to apply the result of the call?
A small example (if it is significantly different from the one above) 
would be very helpful for me to understand this point.

> For the same reason the implementation below won't work - very often 
> you just pass a symbol that evaluates to a function and always en 
> expression that returns a function and there is no way to distinguish 
> that from your new proposed syntax.
Even with () or {} around such "dotted" expression?


> When you feel compelled to use substitute() you should hear alarm 
> bells that something is wrong ;). You can certainly write a new 
> function that uses a different syntax (and I'm sure someone has 
> already done that in the package space), but what you propose is 
> incompatible with *apply in R (and very much not R syntax). Cheers, Simon
>> To illustrate a possible implementation, I propose a wrapper example 
>> for sapply(): wsapply=function(l, fun, ...) { s=substitute(fun) if 
>> (is.name(s) || is.call(s) && s[[1]]==as.name("function")) { sapply(l, 
>> fun, ...) # legacy call } else { sapply(l, function(d) eval(s, 
>> list(.=d)), ...) } } Now, we can do: wsapply(split(mtcars, 
>> mtcars$cyl), summary(lm(mpg ~ wt, .))$r.squared) or, traditional way: 
>> wsapply(split(mtcars, mtcars$cyl), function(d) summary(lm(mpg ~ wt, 
>> d))$r.squared) the both work. How do you feel about that? Best, 
>> Serguei. ______________________________________________ 
>> R-devel using r-project.org mailing list 
>> https://stat.ethz.ch/mailman/listinfo/r-devel 

More information about the R-devel mailing list