Message-ID: <c94d077a-ca00-21d9-d4db-4e494d0d4ded@gmail.com>
Date: 2021-11-08T17:11:51Z
From: John C Nash
Subject: [R-pkg-devel] R feature suggestion: Duplicated function arguments check
In-Reply-To: <22cd1b12-f0f3-a711-50b8-567482833d13@gmail.com>
I think this is similar in nature (though not detail) to an issue raised
on StackOverflow where the OP used "x" in dot args and it clashed with the
"x" in a numDeriv call in my optimx package. I've got a very early fix (I
think), though moderators on StackOverflow were unpleasant enough to
delete my request for the OP to contact me so I could get more
information to make improvements. Sigh. Developers need conversations
with users to improve their code.
Re: argument duplication -- In my view, the first goal should be to inform
the user of the clash. Doing anything further without providing information
is likely a very bad idea, though discussion of possibilities of action after
notification is certainly worthwhile.
Best, JN
On 2021-11-08 11:53 a.m., Duncan Murdoch wrote:
> On 08/11/2021 11:48 a.m., Avi Gross via R-package-devel wrote:
>> Vincent,
>>
>> But is the second being ignored the right result?
>>
>> In many programming situations, subsequent assignments replace earlier ones.
>> And consider the way R allows something like this:
>>
>> func(a=2, b=3, a=4, c=a*b)
>>
>> Is it clear how to initialize the default for c as it depends on one value
>> of "a" or the other?
>
> That c=a*b only works with non-standard tidyverse evaluation.? It causes other problems, e.g. the inability to pass ...
> properly (see https://github.com/tidyverse/glue/issues/231 for an example).
>
> Duncan Murdoch
>
>>
>> Of course, you could just make multiple settings an error rather than
>> choosing an arbitrary fix.
>>
>> R lists are more like a BAG data structure than a SET.
>>
>> -----Original Message-----
>> From: R-package-devel <r-package-devel-bounces at r-project.org> On Behalf Of
>> Vincent van Hees
>> Sent: Monday, November 8, 2021 11:25 AM
>> To: Duncan Murdoch <murdoch.duncan at gmail.com>
>> Cc: r-package-devel at r-project.org
>> Subject: Re: [R-pkg-devel] R feature suggestion: Duplicated function
>> arguments check
>>
>> Thanks Duncan, I have tried to make a minimalistic example:
>>
>> myfun = function(...) {
>> ?? input = list(...)
>> ?? mysum = function(A = c(), B= c()) {
>> ???? return(A+B)
>> ?? }
>> ?? if ("A" %in% names(input) & "B" %in% names(input)) {
>> ???? print(mysum(A = input$A, B = input$B))
>> ?? }
>> }
>>
>> # test:
>>> myfun(A = 1, B = 2, B = 4)
>> [1] 3
>>
>> # So, the second B is ignored.
>>
>>
>>
>> On Mon, 8 Nov 2021 at 17:03, Duncan Murdoch <murdoch.duncan at gmail.com>
>> wrote:
>>
>>> On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
>>>> Not sure if this is the best place to post this message, as it is
>>>> more
>>> of a
>>>> suggestion than a question.
>>>>
>>>> When an R function accepts more than a handful of arguments there is
>>>> the risk that users accidentally provide arguments twice, e.g
>>>> myfun(A=1, B=2, C=4, D=5, A=7), and if those two values are not the
>>>> same it can have frustrating side-effects. To catch this I am
>>>> planning to add a check for duplicated arguments, as shown below, in
>>>> one of my own functions. I am
>>> now
>>>> wondering whether this would be a useful feature for R itself to
>>>> operate
>>> in
>>>> the background when running any R function that has more than a
>>>> certain number of input arguments.
>>>>
>>>> Cheers, Vincent
>>>>
>>>> myfun = function(...) {
>>>> ??? #check input arguments for duplicate assignments
>>>> ??? input = list(...)
>>>> ??? if (length(input) > 0) {
>>>> ????? argNames = names(input)
>>>> ????? dupArgNames = duplicated(argNames)
>>>> ????? if (any(dupArgNames)) {
>>>> ??????? for (dupi in unique(argNames[dupArgNames])) {
>>>> ????????? dupArgValues = input[which(argNames %in% dupi)]
>>>> ????????? if (all(dupArgValues == dupArgValues[[1]])) { # double
>>> arguments,
>>>> but no confusion about what value should be
>>>> ??????????? warning(paste0("\nArgument ", dupi, " has been provided
>>>> more
>>> than
>>>> once in the same call, which is ambiguous. Please fix."))
>>>> ????????? } else { # double arguments, and confusion about what value
>>> should
>>>> be,
>>>> ??????????? stop(paste0("\nArgument ", dupi, " has been provided more
>>>> than once in the same call, which is ambiguous. Please fix."))
>>>> ????????? }
>>>> ??????? }
>>>> ????? }
>>>> ??? }
>>>> ??? # rest of code...
>>>> }
>>>>
>>>
>>> Could you give an example where this is needed?? If a named argument
>>> is duplicated, R will catch that and give an error message:
>>>
>>> ??? > f(a=1, b=2, a=3)
>>> ??? Error in f(a = 1, b = 2, a = 3) :
>>> ????? formal argument "a" matched by multiple actual arguments
>>>
>>> So this can only happen when it is an argument in the ... list that is
>>> duplicated.? But usually those are passed to some other function, so
>>> something like
>>>
>>> ??? g <- function(...) f(...)
>>>
>>> would also catch the duplication in g(a=1, b=2, a=3):
>>>
>>> ??? > g(a=1, b=2, a=3)
>>> ??? Error in f(...) :
>>> ????? formal argument "a" matched by multiple actual arguments
>>>
>>> The only case where I can see this getting by is where you are never
>>> using those arguments to match any formal argument, e.g.
>>>
>>> ??? list(a=1, b=2, a=3)
>>>
>>> Maybe this should have been made illegal when R was created, but I
>>> think it's too late to outlaw now:? I'm sure there are lots of people
>>> making use of this.
>>>
>>> Or am I missing something?
>>>
>>> Duncan Murdoch
>>>
>>
>> ????[[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel