Personally, I find the current syntax much clearer and readable
(defining anything by convention like . being the function variable
seems arbitrary and "dirty" to me), but if you wanted to define a
shorter syntax, you could use something like x ~> i + x. That said, I
really don't see the value of not using function(x) [especially these
days when people are arguing for long variable names with the
justification that IDEs do all the work anyway], but as I said, my
argument was against the actual proposal, not general ideas about
syntax improvement. Cheers, Simon
On 17/04/2020, at 3:53 AM, Sokol Serguei <sokol at insa-toulouse.fr>
wrote: 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 :
On 17/04/2020, at 2:24 AM, Sokol Serguei <sokol at 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.