R Function Call with Ellipsis Trap/Pitfall

Objective if this post: alerting all users to double check case and spelling of all function parameters

I am newbie in R and was trying RSNNS mlp function and wasted a lot of time due to some typos.

RSNNS mlp function silently ignores misspelled keywords
I intentionally misspelled size as hize and maxit as mazit
There are no warnings or errors.

I think that many packages may have same problem as package writers may not always validate ellipsis arguments. I made a small spelling mistake and got puzzling results as there was no parameter validation, but I expected that great eminent packages should be robust and help users recover from typos Let us see what happens with no ellipsis
> square <-function(num ){
+ return(num*num)
+ }
> square(num=4)
[1] 16
> square(numm=4)
Error in square(numm = 4) : unused argument (numm = 4)

# With ellipsis added
> square <-function(num, …){
+ print(names(list(…)));
+ return(num*num)
+ }
> square(num=3,bla=4,kla=9)
[1] “bla” “kla”
[1] 9
As you can see names(list(…)) does give access to parameter names The problem is that ellipsis function calls are for flexibility but package writers should take extra care to throw exception “unused argument” when parameters of functions are misspelled.

This to my mind is a major weakness of the R ecosystem. Most parameters have defaults and small case or spelling mistake can lead to really wrong conclusions!

RSNNS  is simply fantastic but given simply as an example of the ellipsis function call trap. Hope other newbies benefit and learn to avoid the trap of wrong arguments.

Jayanta Narayan Choudhuri
Kolkata India

Published by

Jayanta Choudhuri

IT Consulant based in Kolkata India

2 thoughts on “R Function Call with Ellipsis Trap/Pitfall”

  1. Unfortunately, this just plain won’t work. How would you implement a “almost spelled right” argument name parser? Ellipses are incredibly useful and powerful. If you want to check for unused arguments, then use ‘othernames <- list(…) ' and run a LINT-like search thru the source code for instances of each item. But I would recommend that you add explicit defaults for any arguments that matter, e.g. function ( size = 7, maxit = 3) .That's the only safe way to know whether you overrode the default values for optional arguments.

  2. names(list(…)) gives access
    but unfortunately package writers avoid checking
    extraneous “undocumented” parametsers(result of typos)

    I am resigned to fact this looks like a well known but we will live with it shortcoming in R

    My objective was to highlight this trap

    Too late I agree to change the thousands of CRAN packages

    Without any errror or warning a R user might
    a) Not realize that he has atype and R package silently runs with no alert
    b) Not realize that “real” parameter still has default

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.