Re: [R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Thank you, Simon!

On 11/8/21 5:57 PM, Simon Urbanek wrote:

 From CRAN Policy:



Explain any change in the maintainer’s email address and if possible send 
confirmation from the previous address (by a separate email to 
cran-submissi...@r-project.org) or explain why it is not possible



Cheers,
Simon



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] How to update the email address of a package maintainer

[Simon Urbanek]

>From CRAN Policy:


> Explain any change in the maintainer’s email address and if possible send 
> confirmation from the previous address (by a separate email to 
> cran-submissi...@r-project.org) or explain why it is not possible
> 


Cheers,
Simon

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] How to update the email address of a package maintainer

[Balasubramanian Narasimhan]

Is there any way at all to update the email address of the maintainer of 
a package? (The address of the maintainer of CVXR which is in need of an 
update for the new SCS solver has changed from  @stanford.edu to 
@alumni.stanford.edu, with no access to the former.)


-Naras

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[J C Nash]

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  On Behalf Of
Vincent van Hees
Sent: Monday, November 8, 2021 11:25 AM
To: Duncan Murdoch 
Cc: r-package-devel@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 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Duncan Murdoch]

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  On Behalf Of
Vincent van Hees
Sent: Monday, November 8, 2021 11:25 AM
To: Duncan Murdoch 
Cc: r-package-devel@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 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Avi Gross via R-package-devel]

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?

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  On Behalf Of
Vincent van Hees
Sent: Monday, November 8, 2021 11:25 AM
To: Duncan Murdoch 
Cc: r-package-devel@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 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Vincent van Hees]

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 
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Avi Gross via R-package-devel]

Duncan,

This may not be the place to discuss this so I will be brief.

The question is whether it should be some kind of error to call a function
with two named arguments that are the same.

I can think of a perhaps valid use when a function expects to take the first
few arguments for personal use and then uses ... to pass the rest along to
other functions it calls.

so in your case, slightly extended:

f(a=1, b=2, a=3, c=-5)

The function might pass along to another function:
other(arg, ...)
which would be seen as:
other(arg, a=3, c=-5)

There can of course be other ways to get this result but probably not as
simple. And note this can go several layers deep as various functions call
each other and each has a different need and even meaning for a=something.

Avi
-Original Message-
From: R-package-devel  On Behalf Of
Duncan Murdoch
Sent: Monday, November 8, 2021 11:04 AM
To: Vincent van Hees ;
r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] R feature suggestion: Duplicated function
arguments check

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Georgi Boshnakov]

It turns out that it is not difficult to find, the excerpt below is from 
help(setMethod). Maybe  mentioning this in help(setGeneric) would be helpful, 
as well.

Georgi Boshnakov


===
Method definitions can have default expressions for arguments, but
 only if the generic function must have _some_ default expression
 for the same argument. (This restriction is imposed by the way R
 manages formal arguments.)  If so, and if the corresponding
 argument is missing in the call to the generic function, the
 default expression in the method is used.  If the method
 definition has no default for the argument, then the expression
 supplied in the definition of the generic function itself is used,
 but note that this expression will be evaluated using the
 enclosing environment of the method, not of the generic function.
 Method selection does not evaluate default expressions.  All
 actual (non-missing) arguments in the signature of the generic
 function will be evaluated when a method is selected-when the call
 to 'standardGeneric(f)' occurs.  Note that specifying class
 '"missing"' in the signature does not require any default
 expressions.

-Original Message-
From: Martin Maechler  
Sent: 08 November 2021 15:44
To: Georgi Boshnakov 
Cc: Andrew Simmons ; Dario Strbenac 
; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

> Georgi Boshnakov 
> on Mon, 8 Nov 2021 09:46:00 + writes:

> You need to define the generic with a default value for
> this parameter. Methods can then have a different default
> value for it. 
> I remember reading this in S4's documentation but don't remember where.

> Georgi Boshnakov

interesting ... and would make quite some sense.

Can others confirm / disprove ?

Even as co-author of the "using S4 almost everywhere" package 'Matrix'
I wouldn't have known this.

If this is seen to be true (I don't have time for checking just now), I think 
it's something we really *should* add to one or more of the related help pages.

Martin Maechler


> 

> Sent: Monday, November 8, 2021 5:37:18 AM
> To: Dario Strbenac 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>> From the line `function(A, B) standardGeneric("SetOfParams")`, A and B 
will
> always have default values of R_MissingArg
> Providing default values within the methods does nothing since A and B 
have
> already been initialized before arriving at the method.
> You could do something like:


> if (missing(A))
> A <- ...
> if (missing(B))
> B <- ...


> within each method, and that would emulate having default values for A and
> B.

> On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 

> wrote:

>> Good day,
>> 
>> How can a parameter take a default value from a vector of permitted ones,
>> if it is missing?
>> 
>> setClassUnion("characterOrMissing", c("character", "missing"))
>> setClassUnion("integerOrMissing", c("integer", "missing"))
>> setClass("SetOfParams", representation(A = "characterOrMissing", B =
>> "integer"))
>> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>> 
>> setMethod("SetOfParams", c("missing", "missing"), function() # Empty 
constructor
>> {
>> new("SetOfParams", A = "M", B = 100L)
>> })
>> 
>> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
>> function(A = c("L", "M", "N"), B = 100L)
>> {
>> A <- match.arg(A)
>> new("SetOfParams", A = A, B = B)
>> })
>> 
>> SetOfParams(B = 500L)
>> Error in match.arg(A) : argument "A" is missing, with no default.
>> 
>> How can I avoid the error about A having no default? I thought I 
specified
>> it so that it does have one, which match.arg would set for me if the user
>> did not specify one.
>> 
>> --
>> Dario Strbenac
>> University of Sydney
>> Camperdown NSW 2050
>> Australia
>> __
>> R-package-devel@r-project.org mailing list

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Duncan Murdoch]

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

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Martin Maechler]

> Georgi Boshnakov 
> on Mon, 8 Nov 2021 09:46:00 + writes:

> You need to define the generic with a default value for
> this parameter. Methods can then have a different default
> value for it. 
> I remember reading this in S4's documentation but don't remember where.

> Georgi Boshnakov

interesting ... and would make quite some sense.

Can others confirm / disprove ?

Even as co-author of the "using S4 almost everywhere" package 'Matrix'
I wouldn't have known this.

If this is seen to be true (I don't have time for checking just now),
I think it's something we really *should* add to one or more of
the related help pages.

Martin Maechler


> 

> Sent: Monday, November 8, 2021 5:37:18 AM
> To: Dario Strbenac 
> Cc: r-package-devel@r-project.org 
> Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>> From the line `function(A, B) standardGeneric("SetOfParams")`, A and B 
will
> always have default values of R_MissingArg
> Providing default values within the methods does nothing since A and B 
have
> already been initialized before arriving at the method.
> You could do something like:


> if (missing(A))
> A <- ...
> if (missing(B))
> B <- ...


> within each method, and that would emulate having default values for A and
> B.

> On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 

> wrote:

>> Good day,
>> 
>> How can a parameter take a default value from a vector of permitted ones,
>> if it is missing?
>> 
>> setClassUnion("characterOrMissing", c("character", "missing"))
>> setClassUnion("integerOrMissing", c("integer", "missing"))
>> setClass("SetOfParams", representation(A = "characterOrMissing", B =
>> "integer"))
>> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>> 
>> setMethod("SetOfParams", c("missing", "missing"), function() # Empty 
constructor
>> {
>> new("SetOfParams", A = "M", B = 100L)
>> })
>> 
>> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
>> function(A = c("L", "M", "N"), B = 100L)
>> {
>> A <- match.arg(A)
>> new("SetOfParams", A = A, B = B)
>> })
>> 
>> SetOfParams(B = 500L)
>> Error in match.arg(A) : argument "A" is missing, with no default.
>> 
>> How can I avoid the error about A having no default? I thought I 
specified
>> it so that it does have one, which match.arg would set for me if the user
>> did not specify one.
>> 
>> --
>> Dario Strbenac
>> University of Sydney
>> Camperdown NSW 2050
>> Australia
>> __
>> R-package-devel@r-project.org mailing list

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Vincent van Hees]

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...
}

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

[Georgi Boshnakov]

You need to define  the generic with a default value for this parameter. 
Methods can then have a different default value for it. I remember reading this 
in S4's documentation but don't remember where.

Georgi Boshnakov

Get Outlook for Android

From: R-package-devel  on behalf of 
Andrew Simmons 
Sent: Monday, November 8, 2021 5:37:18 AM
To: Dario Strbenac 
Cc: r-package-devel@r-project.org 
Subject: Re: [R-pkg-devel] match.arg With S4 Methods and Missing Inputs

>From the line `function(A, B) standardGeneric("SetOfParams")`, A and B will
always have default values of R_MissingArg
Providing default values within the methods does nothing since A and B have
already been initialized before arriving at the method.
You could do something like:


if (missing(A))
A <- ...
if (missing(B))
B <- ...


within each method, and that would emulate having default values for A and
B.

On Mon, Nov 8, 2021 at 12:00 AM Dario Strbenac 
wrote:

> Good day,
>
> How can a parameter take a default value from a vector of permitted ones,
> if it is missing?
>
> setClassUnion("characterOrMissing", c("character", "missing"))
> setClassUnion("integerOrMissing", c("integer", "missing"))
> setClass("SetOfParams", representation(A = "characterOrMissing", B =
> "integer"))
> setGeneric("SetOfParams", function(A, B) standardGeneric("SetOfParams"))
>
> setMethod("SetOfParams", c("missing", "missing"), function() # Empty
> constructor
> {
>   new("SetOfParams", A = "M", B = 100L)
> })
>
> setMethod("SetOfParams", c("characterOrMissing", "integerOrMissing"),
> function(A = c("L", "M", "N"), B = 100L)
> {
>   A <- match.arg(A)
>   new("SetOfParams", A = A, B = B)
> })
>
> SetOfParams(B = 500L)
>   Error in match.arg(A) : argument "A" is missing, with no default.
>
> How can I avoid the error about A having no default? I thought I specified
> it so that it does have one, which match.arg would set for me if the user
> did not specify one.
>
> --
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel