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 ah...@pitt.edu (724) 612-9940 From: R-devel <r-devel-boun...@r-project.org> on behalf of mikkmart via R-devel <r-devel@r-project.org> Date: Monday, November 6, 2023 at 17:41 To: r-devel@r-project.org <r-devel@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@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]]
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
