Re:Parsing R code: Freedom of expression is not always a goo...
by abirch on Tuesday June 14, 2022 @07:08AM
(#31737253)
I'm sad that R didn't go closer to JavaScript style for Lambda instead of going toward Haskell, e.g., ‘\(x) x + 1’ vs x=> x+1
[ Parent
| on HN ]
Re:Parsing R code: Freedom of expression is not always a goo...
by wodenokoto on Tuesday June 14, 2022 @08:32AM
(#31738309)
I've always liked that lambda and functions are the same thing in R and write `function(x){x + 1}`
I dislike both of your examples and am glad to have never seen that in any R code I've met.
Re:Parsing R code: Freedom of expression is not always a goo...
by abirch on Tuesday June 14, 2022 @10:59AM
(#31740478)
it's new as of R 4.1 along with the new pipe operator
Re:Parsing R code: Freedom of expression is not always a goo...
by tomlue on Tuesday June 14, 2022 @08:09AM
(#31737963)
I prefer the R formula syntax. i.e
~ . + 1 ~ .x + .y
Re:Parsing R code: Freedom of expression is not always a goo...
by tfehring on Tuesday June 14, 2022 @11:58AM
(#31741313)
I like this syntax better than the new lambda syntax, but I think it's good that a proper lambda syntax exists now. Not all higher-order functions accept formulas (they have to wrap their function arguments with rlang::as_function or equivalent), and there are probably some obscure cases where the distinction between a formula and a function matters.
Re:Parsing R code: Freedom of expression is not always a goo...
by bruce343434 on Tuesday June 14, 2022 @07:50AM
(#31737740)
What's sad about it?
Re:Parsing R code: Freedom of expression is not always a goo...
by reitanqild on Tuesday June 14, 2022 @08:00AM
(#31737846)
JS version is more readable for most people.
(I'm no big fan of JS in general, unless it is TS but I consider that a different language.)