>>>>> William Dunlap <wdun...@tibco.com>
>>>>> on Fri, 30 Mar 2012 16:07:52 +0000 writes:
> It looks like you define a few functions that use substitute() or
sys.call()
> or similar functions to look at the unevaluated argument list. E.g.,
> "cq" <-
> function( ...) {
> # Saves putting in quotes!
> # E.G.: quoted( first, second, third) is the same as c( 'first',
'second', 'third')
> # wrapping by as.character means cq() returns character(0) not list()
> as.character( sapply( as.list( match.call( expand.dots=TRUE))[-1],
as.character))
> }
> %such.that% and %SUCH.THAT% do similar things.
> Almost all the complaints from check involve calls to a
> handful of such functions. If you could tell
> codetools:::checkUsage that that these functions did
> nonstandard evaluation on all or some of their arguments
> then the complaints would go away and other checks for
> real errors like misspellings would still be done.
I agree very much with you, Bill.
Many (if not the majority) of my packages have given these false
positive notes for many months now... and I have to admit that
the effect indeed has been that I take notes much less seriously
nowadays. This of course has never been the intention.
I'm pretty sure that most of us agree that it would be very
useful if not desirable to have a simple and robust way for
package authors to declare nonstandard evaluation to the
checkUsage() checks.
Maybe we should branch a new thread about this, for proposals on
how to go about this.
Martin
> Another possible part of the problem is that if checkUsage
> is checking a function like
> f <- function(x) paste(x, cq(suffix), sep=".")
> it attributes the out-of-scope suffix problem to 'f' and doesn't mention
that the immediate
> caller is 'cq', so you cannot easily filter output complaints about cq.
(CRAN would
> not do such filtering, but a developer might.)
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
>> -----Original Message-----
>> From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf
>> Of mark.braving...@csiro.au
>> Sent: Thursday, March 29, 2012 6:30 PM
>> Cc: r-de...@stat.math.ethz.ch
>> Subject: Re: [Rd] CRAN policies
>>
>> I'm concerned this thread is heading the wrong way, towards techno-fixes
for imaginary
>> problems. R package-building is already encumbered with a huge set of
complicated
>> rules, and more instructions/rules eg for metadata would make things
worse not better.
>>
>>
>> RCMD CHECK on the 'mvbutils' package generates over 300 Notes about "no
visible
>> binding...", which inevitably I just ignore. They arise because RCMD
CHECK is too "stupid"
>> to understand one of my preferred coding idioms (I'm not going to
explain what-- that's
>> beside the point). And RCMD CHECK always will be too "stupid" to
understand everything
>> that a rich language like R might quite reasonably cause experienced
coders to do.
>>
>> It should not be CRAN's business how I write my code, or even whether my
code does
>> what it is supposed to. It might be CRAN's business to try to work out
whether my code
>> breaks CRAN's policies, eg by causing R to crash horribly-- that's
presumably what
>> Warnings are for (but see below). And maybe there could be circumstances
where an
>> automatic check might be "worried" enough to alert the CRANia and
require manual
>> explanation and emails etc from a developer, but even that seems doomed
given the
>> growing deluge of packages.
>>
>> RCMD CHECK currently functions both as a "sanitizer" for CRAN, and as a
developer-tool.
>> But the fact that the one programl does both things seems accidental to
me, and I think
>> this dual-use is muddying the discussion. There's a big distinction
between (i) code-checks
>> that developers themselves might or might not find useful-- which should
be left to the
>> developer, and will vary from person to person-- and (ii) code-checks
that CRAN enforces
>> for its own peace-of-mind. Maybe it's convenient to have both functions
in the same
>> place, and it'd be fine to use Notes for one and Warnings for the other,
but the different
>> purposes should surely be kept clear.
>>
>> Personally, in building over 10 packages (only 2 on CRAN), I haven't
found RCMD CHECK
>> to be of any use, except for the code-documentation and example-running
bits. I know
>> other people have different opinions, but that's the point:
one-size-does-not-fit-all when
>> it comes to coding tools.
>>
>> And wrto the Warnings themselves: I feel compelled to point out that
it's logically
>> impossible to fully check whether R code will do bad things. One has to
wonder at what
>> point adding new checks becomes futile or counterproductive. There must
be over 2000
>> people who have written CRAN packages by now; every extra check and
non-back-
>> compatible additional requirement runs the risk of generating
false-negatives and
>> incurring many extra person-hours to "fix" non-problems. Plus someone
needs to
>> document and explain the check (adding to the rule mountain), plus there
is the time
>> spent in discussions like this..!
>>
>> Mark
>>
>> Mark Bravington
>> CSIRO CMIS
>> Marine Lab
>> Hobart
>> Australia
>> ________________________________________
>> From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On
Behalf Of
>> Hadley Wickham [had...@rice.edu]
>> Sent: 30 March 2012 07:42
>> To: William Dunlap
>> Cc: r-de...@stat.math.ethz.ch; Spencer Graves
>> Subject: Re: [Rd] CRAN policies
>>
>> > 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"
>>
>> It seems like we really need a standard way to add metadata to functions:
>>
>> attr(with, "special_args") <- "expr"
>> attr(lm, "special_args") <- c("formula", "weights", "subset")
>>
>> This would be useful because it could automatically contribute to the
>> documentation.
>>
>> Similarly,
>>
>> attr(my.new.method, "s3method") <- c("my.new", "method")
>>
>> could be useful.
>>
>> Hadley
>>
>>
>> --
>> Assistant Professor / Dobelman Family Junior Chair
>> Department of Statistics / Rice University
>> http://had.co.nz/
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
