From spencer.graves at prodsyse.com  Thu Mar 29 21:21:59 2012
From: spencer.graves at prodsyse.com (Spencer Graves)
Date: Thu, 29 Mar 2012 12:21:59 -0700
Subject: [Rd] CRAN policies
In-Reply-To: <E66794E69CFDE04D9A70842786030B9328EDE3@PA-MBX04.na.tibco.com>
References: <mailman.19.1333015207.14516.r-devel@r-project.org>
	<4F746B54.2050601@mayo.edu>
	<E66794E69CFDE04D9A70842786030B9328EC77@PA-MBX04.na.tibco.com>
	<loom.20120329T190333-975@post.gmane.org>
	<E66794E69CFDE04D9A70842786030B9328EDE3@PA-MBX04.na.tibco.com>
Message-ID: <4F74B657.5040807@prodsyse.com>

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



[Rd] CRAN policies
Spencer Graves