anonymous functions

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be
helpful in making
code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code"
threads: in Fortran,
in C, in Splus, ...   The same old idea that "short" is a synonym for
either elegant,
readable, or efficient is now being recylced in the tidyverse.   The truth
is that "short"
is actually an antonym for all of these things, at least for anyone else
reading the code;
or for the original coder 30-60 minutes after the "clever" lines were
written.  Minimal
use of the spacebar and/or the return key isn't usually held up as a goal,
but creeps into
many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are
people typing code
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many
of my colleagues
think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more
readable.  Every
bug fix or new feature in the survival package now adds more lines of
comments or other
documentation than lines of code.  If I have to puzzle out what a line
does, what about
the poor sod who inherits the maintainance?


--
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
therneau at mayo.edu

"TERR-ree THUR-noh"

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be 
helpful in making code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: 
in Fortran, in C, in Splus, ...   The same old idea that "short" is a synonym 
for either elegant, readable, or efficient is now being recylced in the 
tidyverse.   The truth is that "short" is actually an antonym for all of 
these things, at least for anyone else reading the code; or for the original 
coder 30-60 minutes after the "clever" lines were written.  Minimal use of 
the spacebar and/or the return key isn't usually held up as a goal, but 
creeps into many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are people 
typing code with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of 
my colleagues think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more 
readable.  Every bug fix or new feature in the survival package now adds more 
lines of comments or other documentation than lines of code.  If I have to 
puzzle out what a line does, what about the poor sod who inherits the 
maintainance?

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in making
code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in Fortran,
in C, in Splus, ...   The same old idea that "short" is a synonym for either elegant,
readable, or efficient is now being recylced in the tidyverse.   The truth is that "short"
is actually an antonym for all of these things, at least for anyone else reading the code;
or for the original coder 30-60 minutes after the "clever" lines were written.  Minimal
use of the spacebar and/or the return key isn't usually held up as a goal, but creeps into
many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are people typing code
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of my colleagues
think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more readable.  Every
bug fix or new feature in the survival package now adds more lines of comments or other
documentation than lines of code.  If I have to puzzle out what a line does, what about
the poor sod who inherits the maintainance?


--
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
therneau at mayo.edu

"TERR-ree THUR-noh"

I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are compatible within tidyverse but not
with others). And of course none work in sapply or lapply. Providing a
shorthand in base may help to improve this. You don't have to use it
if you don't want to, and you can establish coding standards that
disallow it if you like.

Best,

luke

On Mon, 7 Dec 2020, Therneau, Terry M., Ph.D. via R-devel wrote:

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in 
making code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in 
Fortran, in C, in Splus, ...?? The same old idea that "short" is a synonym for either 
elegant, readable, or efficient is now being recylced in the tidyverse.?? The truth is 
that "short" is actually an antonym for all of these things, at least for anyone else 
reading the code; or for the original coder 30-60 minutes after the "clever" lines were 
written. Minimal use of the spacebar and/or the return key isn't usually held up as a 
goal, but creeps into many practiioner's code as well.

People are excited by replacing "function(" with "\("? Really??? Are people typing code 
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of my 
colleagues think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more readable.? 
Every bug fix or new feature in the survival package now adds more lines of comments or 
other documentation than lines of code.? If I have to puzzle out what a line does, what 
about the poor sod who inherits the maintainance?

f <- function(x, xlab=deparse1(substitute(x))) paste(sep="", xlab, ": ",

2^(1:4)  |> f()

2^(1:4)  %>% f()

dput(quote(2^(1:4)  |> f()))

Luke,
   Mostly an aside.  I think that pipes are a good addition, and it is
clear that you and
other R-core thought through many of the details.   Congratulations on
what appears to be
solid work. I've used Unix since '79, so it is almost guarranteed that I
like the basic
idiom, and I expect to make use of it.  Users who think that pipes -- or
any other code --
is so clear that comments are superfluous is no reflection on R core, and
also a bit of a
hobby horse for me.

I am a bit bemused by the flood of change suggestions, before people have
had a chance to
fully exercise the new code.   I'd suggest waiting several months, or a
year, before major
updates, straight up bugs excepted.   The same advice holds when moving
into a new house.
One  experience with the survival package has been that most new ideas
have been
implemented locally, and we run with them for half a year before
submission to CRAN.  I've
had a few "really great" modifications that, thankfully, were never
inflicted on the rest
of the R community.

Terry T.

On 12/7/20 11:26 AM, luke-tierney at uiowa.edu wrote:

I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are compatible within tidyverse but not
with others). And of course none work in sapply or lapply. Providing a
shorthand in base may help to improve this. You don't have to use it
if you don't want to, and you can establish coding standards that
disallow it if you like.

Best,

luke

On Mon, 7 Dec 2020, Therneau, Terry M., Ph.D. via R-devel wrote:

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may

be helpful in

making code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code"

threads: in

Fortran, in C, in Splus, ...   The same old idea that "short" is a

synonym for either

elegant, readable, or efficient is now being recylced in the

tidyverse.   The truth is

that "short" is actually an antonym for all of these things, at least

for anyone else

reading the code; or for the original coder 30-60 minutes after the

"clever" lines were

written. Minimal use of the spacebar and/or the return key isn't

usually held up as a

goal, but creeps into many practiioner's code as well.

People are excited by replacing "function(" with "\("? Really?   Are

people typing code

with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too

many of my

colleagues think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and

more readable.

Every bug fix or new feature in the survival package now adds more

lines of comments or

other documentation than lines of code.  If I have to puzzle out what a

line does, what

about the poor sod who inherits the maintainance?

        [[alternative HTML version deleted]]

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in making
code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in Fortran,
in C, in Splus, ...   The same old idea that "short" is a synonym for either elegant,
readable, or efficient is now being recylced in the tidyverse.   The truth is that "short"
is actually an antonym for all of these things, at least for anyone else reading the code;
or for the original coder 30-60 minutes after the "clever" lines were written.  Minimal
use of the spacebar and/or the return key isn't usually held up as a goal, but creeps into
many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are people typing code
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of my colleagues
think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more readable.  Every
bug fix or new feature in the survival package now adds more lines of comments or other
documentation than lines of code.  If I have to puzzle out what a line does, what about
the poor sod who inherits the maintainance?


--
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
therneau at mayo.edu

"TERR-ree THUR-noh"

I mostly agree with your comments on anonymous functions.

However, I think the main problem is cryptic-ness, rather than succinct-ness.
The backslash is a relatively universal symbol within programming
languages with C-like (ALGOL-like?) syntax.
Where it denotes escape sequences within strings.

Using the leading character for escape sequences, to define functions,
is like using integers to define floating point numbers:

    my.integer <- as.integer (2) * pi

Arguably, the motive is more to be ultra-succinct than cryptic.
But either way, we get syntax which is difficult to read, from a
mathematical and statistical perspective.


On Tue, Dec 8, 2020 at 6:04 AM Therneau, Terry M., Ph.D. via R-devel
<r-devel at r-project.org> wrote:

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in making
code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in Fortran,
in C, in Splus, ...   The same old idea that "short" is a synonym for either elegant,
readable, or efficient is now being recylced in the tidyverse.   The truth is that "short"
is actually an antonym for all of these things, at least for anyone else reading the code;
or for the original coder 30-60 minutes after the "clever" lines were written.  Minimal
use of the spacebar and/or the return key isn't usually held up as a goal, but creeps into
many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are people typing code
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of my colleagues
think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more readable.  Every
bug fix or new feature in the survival package now adds more lines of comments or other
documentation than lines of code.  If I have to puzzle out what a line does, what about
the poor sod who inherits the maintainance?


--
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
therneau at mayo.edu

"TERR-ree THUR-noh"

On 8 Dec 2020, at 00:05, Abby Spurdle <spurdle.a at gmail.com> wrote:

?Sorry, I should replace "cryptic-ness" from my last post, with
"unnecessary cryptic-ness".
Sometimes short symbolic expressions are necessary.


P.S.
Often, I wish I could write: f (x) = x^2.
But that's replacement function syntax.

On Tue, Dec 8, 2020 at 11:56 AM Abby Spurdle <spurdle.a at gmail.com> wrote:

I mostly agree with your comments on anonymous functions.

However, I think the main problem is cryptic-ness, rather than succinct-ness.
The backslash is a relatively universal symbol within programming
languages with C-like (ALGOL-like?) syntax.
Where it denotes escape sequences within strings.

Using the leading character for escape sequences, to define functions,
is like using integers to define floating point numbers:

   my.integer <- as.integer (2) * pi

Arguably, the motive is more to be ultra-succinct than cryptic.
But either way, we get syntax which is difficult to read, from a
mathematical and statistical perspective.

On Tue, Dec 8, 2020 at 6:04 AM Therneau, Terry M., Ph.D. via R-devel
<r-devel at r-project.org> wrote:

?The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be helpful in making
code containing simple function expressions more readable.?

Color me unimpressed.
Over the decades I've seen several "who can write the shortest code" threads: in Fortran,
in C, in Splus, ...   The same old idea that "short" is a synonym for either elegant,
readable, or efficient is now being recylced in the tidyverse.   The truth is that "short"
is actually an antonym for all of these things, at least for anyone else reading the code;
or for the original coder 30-60 minutes after the "clever" lines were written.  Minimal
use of the spacebar and/or the return key isn't usually held up as a goal, but creeps into
many practiioner's code as well.

People are excited by replacing "function(" with "\("?  Really?   Are people typing code
with their thumbs?
I am ambivalent about pipes: I think it is a great concept, but too many of my colleagues
think that using pipes = no need for any comments.

As time goes on, I find my goal is to make my code less compact and more readable.  Every
bug fix or new feature in the survival package now adds more lines of comments or other
documentation than lines of code.  If I have to puzzle out what a line does, what about
the poor sod who inherits the maintainance?


--
Terry M Therneau, PhD
Department of Health Science Research
Mayo Clinic
therneau at mayo.edu

"TERR-ree THUR-noh"

I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are compatible within tidyverse but not
with others). And of course none work in sapply or lapply. Providing a
shorthand in base may help to improve this. You don't have to use it
if you don't want to, and you can establish coding standards that
disallow it if you like.

On 07/12/2020 12:26 p.m., luke-tierney at uiowa.edu wrote:

I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are compatible within tidyverse but not
with others). And of course none work in sapply or lapply. Providing a
shorthand in base may help to improve this. You don't have to use it
if you don't want to, and you can establish coding standards that
disallow it if you like.

Here's a suggestion to let people define their own shorthands and work
with the current |> definition.

Define "as.call" as an S3 generic, with a default definition something like >
as.call.default <- function(x, f, ...) f(x, ...)

so one could use

   x |> as.call(mean)

to get the same result as

   x |> mean()

or (if working in the tidyverse)

   x |> as.call(~ .x + 1)

to use a method to be provided by rlang or purrr to convert their
shorthand into a call that the pipe can work with.

We already have the generic as.function, which could be used internally
by lapply and sapply for the same sort of purpose.  tidyverse has
rlang::as_function, so they could pretty easily add methods for
as.function if they wanted to allow people to use their shorthand in
*apply functions.

Duncan Murdoch

I don't disagree in principle, but the reality is users want shortcuts
and as a result various packages, in particular tidyverse, have been
providing them. Mostly based on formulas, mostly with significant
issues since formulas weren't designed for this, and mostly
incompatible (tidyverse ones are compatible within tidyverse but not
with others). And of course none work in sapply or lapply.