Sergei,
the main problem that I was pointing out is is that there is no way you can
introduce the new syntax without breaking the old one. The expression is
evaluated to obtain a function, so by definition using anything that results in
a valid expression for your syntax will break. E.g., using sapply(x, (foo)) is
completely valid so you can't just change the evaluation of the expression to
something different (which is what you're doing). As people were pointing out
there are many ways to do this if you change the syntax.
I'm not arguing against the principle, I'm arguing about your particular
proposal as it is inconsistent and not general. 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 <so...@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 :
>> 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
