[Rd] New syntax for positional-only function parameters?

[Lakshman, Aidan H]

Hi Mikko,

> Given the prevalence of the issue, is this something that you would see as worth pursuing for R?

Could you give a little more detail on this, potentially with an example of the collisions you�re referring to (and maybe an example that throws an error and/or does something unexpected)? I can�t think of a time I�ve had an issue that would have been solved/helped with positional-only parameters, though it could just be a use-case outside of my normal work. Typically, the default scoping rules are sufficient to resolve these in a way that feels (to me at least) pretty intuitive.

> The typical workaround is to use somehow obfuscated names for the parameters in the main function in order to make such collisions unlikely�In practice this pattern avoids many collisions, but it cannot guarantee that they won't happen.

This is a fair point and the PEP you linked is a great writeup, but it�s worth mentioning that the development paradigms of Python and R aren�t exactly the same. My gut feeling is that this change would take a significant amount of work to solve a somewhat edge case. Anything involving changes to the argument parser has a nontrivial chance of inadvertently affecting other pieces of R, and with R�s focus on stability and backwards-compatibility they typically try to avoid big changes to the core core functionality. I am not R-core, but I�d be doubtful that it would be a high priority project for the core members for those reasons. Again, if there were examples of packages/code that would be simplified by this then that could change things, although I doubt that any changes would be made to functions like the `*apply` family due to backwards-compatibility issues.

That said, it�s an interesting idea. If you have an implementation that adds this capability, I�d be interested in taking a look. From a quick look at the internals, I�m expecting you�d need to make a few changes to `src/main/builtin.c` and possibly `src/main/eval.c`. I�m far from an expert on this, so I�d also be interested in anyone else�s input.

-Aidan

-----------------------
Aidan Lakshman (he/him)<https://www.ahl27.com/>
Doctoral Fellow, Wright Lab<https://www.wrightlabscience.com/>
University of Pittsburgh School of Medicine
Department of Biomedical Informatics
ahl27 using pitt.edu
(724) 612-9940


From: R-devel <r-devel-bounces using r-project.org> on behalf of mikkmart via R-devel <r-devel using r-project.org>
Date: Monday, November 6, 2023 at 17:41
To: r-devel using r-project.org <r-devel using r-project.org>
Subject: [Rd] New syntax for positional-only function parameters?
Dear List,

I'm writing to gauge interest in new syntax for positional-only
function parameters to be added to R.

The pattern of functions accepting other functions as inputs and
passing additional ... arguments to them is prevalent throughout
the R ecosystem. Currently, however, all such functions must one
way or another tackle the problem of inadvertently passing arguments
meant to go to ... as arguments to the function itself instead.

The typical workaround is to use somehow obfuscated names for the
parameters in the main function in order to make such collisions
unlikely. For example lapply() and friends with signatures like:

    function (X, FUN, ...)

In practice this pattern avoids many collisions, but it cannot
guarantee that they won't happen. It would seem to me preferrable
to avoid the root cause of the issue altogether by having the
language feature of declaring function parameters as positional-only.

Python's PEP 570 discusses the same issue in the context of Python [1].

Concretely, borrowing syntax from Python, the proposal would be
to have something along the lines of:

    g <- function(x, f, /, ...) match.call()
    g(1, f, x = 2) == quote(g(1, f, x = 2))

Rather than the current situation of:

    g <- function(x, f, ...) match.call()
    g(1, f, x = 2) == quote(g(x = 2, f = 1, f))

Given the prevalence of the issue, is this something that you would
see as worth pursuing for R?

Best regards,

Mikko

[1]: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeps.python.org%2Fpep-0570%2F&data=05%7C01%7Cahl27%40pitt.edu%7C14977c4a084b4005d90508dbdf197ca3%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1%7C0%7C638349072804739356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0RtGGMmsrx9YTC23ZHD2qLRUXvb%2Fd9JqBWvn1VYaul8%3D&reserved=0<https://peps.python.org/pep-0570/>

______________________________________________
R-devel using r-project.org mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=05%7C01%7Cahl27%40pitt.edu%7C14977c4a084b4005d90508dbdf197ca3%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1%7C0%7C638349072804739356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=18L686XGln2pUwUIjIFvaqyn8BgoC2uS%2Fw2ZMkTBUCc%3D&reserved=0<https://stat.ethz.ch/mailman/listinfo/r-devel>

	[[alternative HTML version deleted]]