Simon,
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 <so...@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)
l[[1]](3)
# 4
l[[2]](3)
# 5
This is indeed a corner case but a pair of () or {} can keep wsapply()
in course:
l=wsapply(1:3, (function(x) .+x))
l[[1]](3)
# 4
l[[2]](3)
# 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?
Best,
Serguei.
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
