[Rd] CRAN policies

[William Dunlap]

> > codetools should be able to do special checks for known functions that
> > do not following the standard evaluation rules .   E.g., do not check any
> > arguments of `~`, do not check the 'expr' argument of with, do not check
> > the subset or weights arguments of lm.
> >
> > If a package writer introduces a new function with nonstandard evaluation,
> > perhaps the package could include some information about the matter
> > in a file that codetools could could source before running its checks.
> 
> 
>        This gets my vote -- but I don't have the bandwidth nor authority
> to effect the change ;-)  Spencer

Most of that stuff is already in codetools, at least when it is checking functions
with checkUsage().  E.g., arguments of ~ are not checked.  The  expr argument
to with() will not be checked if you add  skipWith=FALSE to the call to checkUsage.

  > library(codetools)

  > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}))
  <anonymous>: no visible binding for global variable 'Num' (:1)
  <anonymous>: no visible binding for global variable 'Den' (:1)

  > checkUsage(function(dataFrame) with(dataFrame, {Num/Den ; Resp ~ Pred}), skipWith=TRUE)

  > checkUsage(function(dataFrame) with(DataFrame, {Num/Den ; Resp ~ Pred}), skipWith=TRUE)
  <anonymous>: no visible binding for global variable 'DataFrame'

The only part that I don't see is the mechanism to add code-walker functions to
the environment in codetools that has the standard list of them for functions with
nonstandard evaluation:
  > objects(codetools:::collectUsageHandlers, all=TRUE)
   [1] "$"             "$<-"           ".Internal"    
   [4] "::"            ":::"           "@"            
   [7] "@<-"           "{"             "~"            
  [10] "<-"            "<<-"           "="            
  [13] "assign"        "binomial"      "bquote"       
  [16] "data"          "detach"        "expression"   
  [19] "for"           "function"      "Gamma"        
  [22] "gaussian"      "if"            "library"      
  [25] "local"         "poisson"       "quasi"        
  [28] "quasibinomial" "quasipoisson"  "quote"        
  [31] "Quote"         "require"       "substitute"   
  [34] "with"         

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com


> -----Original Message-----
> From: Spencer Graves [mailto:spencer.graves at prodsyse.com]
> Sent: Thursday, March 29, 2012 12:22 PM
> To: William Dunlap
> Cc: Matthew Dowle; r-devel at stat.math.ethz.ch
> Subject: Re: [Rd] CRAN policies
> 
> On 3/29/2012 11:29 AM, William Dunlap wrote:
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >
> >
> >> -----Original Message-----
> >> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On
> Behalf
> >> Of Matthew Dowle
> >> Sent: Thursday, March 29, 2012 10:41 AM
> >> To: r-devel at stat.math.ethz.ch
> >> Subject: Re: [Rd] CRAN policies
> >>
> >> William Dunlap<wdunlap<at>  tibco.com>  writes:
> >>
> >>>> -----Original Message-----
> >>>> The survival package has a similar special case: the routines for
> >>>> expected population survival are set up to accept multiple types of date
> >>>> format so have lines like
> >>>>       if (class(x) == 'chron') { y<- as.numeric(x - chron("01/01/1960")}
> >>>> This leaves me with two extraneous "no visible binding" messages.
> >>> Suppose we defined a function like
> >>>    NO_VISIBLE_BINDING(expr) expr
> >>> and added an entry to the stuff in codetools so that it
> >>> would not check for misspelled object names in call to
> >>> NO_VISIBLE_BINDING.  Then Terry could write that line as
> >>>       if (class(x) == "chron") { y<- as.numeric(x - NO_VISIBLE_BINDING(chron)
> >> ("01/01/1960")}
> >>> and the Notes would disappear.
> >>>
> >> That's ok for package code, but what about test suites?  Say there was a test
> >> on the result of "with(DF,a+b)", you wouldn't want to change the test to "with
> >> (DF,NO_VISIBLE_BINDING(a)+NO_VISIBLE_BINDING(b))" not just because that's long
> >> and onerous, but because that's *changing* the test i.e. introducing a
> >> difference between what's tested and what user code will do.
> > I don't know if test suites need to be checked for no visible bindings -
> > if there is a real problem the test ought to fail.
> >
> > codetools should be able to do special checks for known functions that
> > do not following the standard evaluation rules .   E.g., do not check any
> > arguments of `~`, do not check the 'expr' argument of with, do not check
> > the subset or weights arguments of lm.
> >
> > If a package writer introduces a new function with nonstandard evaluation,
> > perhaps the package could include some information about the matter
> > in a file that codetools could could source before running its checks.
> 
> 
>        This gets my vote -- but I don't have the bandwidth nor authority
> to effect the change ;-)  Spencer
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >> As others suggested, how about a new category: MEMO. The "no visible binding"
> >> NOTE would be downgraded to MEMO. CRAN maintainers could then ignore MEMOs
> >> more
> >> easily.
> >>
> >> What I really like about NOTES is that when new checks are added to R then as a
> >> package maintainer you know you don't have to fix them straight away. If a new
> >> WARNING shows up on r-devel daily checks, however, then you've got some warning
> >> about the WARNING that you need to fix more urgently and may even accelerate a
> >> release. So it's not just about checks when submitting a package, but what
> >> happens afterwards as R itself (and packages in Depends) move on. In other
> >> words, you know you need to fix new NOTES but not as urgently as new WARNINGS.
> >>
> >> Matthew
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>