From xie at yihui.name  Sat May 31 06:22:03 2014
From: xie at yihui.name (Yihui Xie)
Date: Fri, 30 May 2014 23:22:03 -0500
Subject: [Rd] R CMD check for the R code from vignettes
In-Reply-To: <538885F3.8020807@gmail.com>
References: <CANROs4dyoXEUEzouGTsL9sHCMM8RcjYWw9584SUAEYfGntPrFg@mail.gmail.com>
	<538885F3.8020807@gmail.com>
Message-ID: <CANROs4eect+qAvXTLEzPhM=X2Eg5R0T-DCUBO6=VDfBFVJNCuQ@mail.gmail.com>

Hi Kevin,

Personally I also avoid code that have side effects in the inline
expressions, but I think there are legitimate use cases in which
inline expressions have side effects. This discussion was motivated by
Carl's knitcitations package, as well as another question on
StackOverflow (http://stackoverflow.com/q/23927325/559676).

I'm aware of the distinction between the original literate programming
paradigm and the one in R (that is why I said "literate programming in
R" instead of "literate programming in general"). In R, weave actually
does what both weave and tangle do in the original paradigm -- there
is no need to tangle the document to get the computer code so that we
can execute it.

To Carl: I agree that it is a little extreme to drop tangle entirely,
so I think at least knitr::purl() will stay there in the foreseeable
future. I tend to adopt Henrik's idea, i.e., to provide vignette
engines that just ignore tangle. At the moment, it seems R CMD check
is comfortable with vignettes that do not have corresponding R
scripts, and I hope these R scripts will not become mandatory in the
future.

Thanks everyone for your comments!

Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Web: http://yihui.name


On Fri, May 30, 2014 at 8:21 AM, Kevin Coombes
<kevin.r.coombes at gmail.com> wrote:
> Hi,
>
> Unless someone is planning to change Stangle to include inline expressions
> (which I am *not* advocating), I think that relying on side-effects within
> an \Sexpr construction is a bad idea. So, my own coding style is to restrict
> my use of \Sexpr to calls of the form
> \Sexpr{show.the.value.of.this.variable}. As a result, I more-or-less believe
> that having R CMD check use Stangle and report an error is probably a good
> thing.
>
> There is a completely separate questions about the relationship between
> Sweave/Stangle or knit/purl and literate programming that is linked to your
> question about whether to use Stangle on vignettes. The underlying model(s)
> in R have drifted away from Knuth's original conception, for some good
> reasons.
>
> The original goal of literate programming was to be able to explain the
> algorithms and data structures in the code to humans.  For that purpose, it
> was important to have named code chunks that you could move around, which
> would allow you to describe the algorithm starting from a high level
> overview and then drilling down into the details. From this perspective,
> "tangle" was critical to being able to reconstruct a program that would
> compile and run correctly.
>
> The vast majority of applications of Sweave/Stangle or knit/purl in modern R
> have a completely different goal: to produce some sort of document that
> describes the results of an analysis to a non-programmer or
> non-statistician.  For this goal, "weave" is much more important than
> "tangle", because the most important aspect is the ability to integrate the
> results (figures, tables, etc) of running the code into the document that
> get passed off to the person for whom the analysis was prepared. As a
> result, the number of times in my daily work that I need to explicitly
> invoke Stangle (or purl) explicitly is many orders of magnitude smaller than
> the number of times that I invoke Sweave (or knitr).
>
>   -- Kevin
>
>
>
> On 5/30/2014 1:04 AM, Yihui Xie wrote:
>>
>> Hi,
>>
>> Recently I saw a couple of cases in which the package vignettes were
>> somewhat complicated so that Stangle() (or knitr::purl() or other
>> tangling functions) can fail to produce the exact R code that is
>> executed by the weaving function Sweave() (or knitr::knit(), ...). For
>> example, this is a valid document that can pass the weaving process
>> but cannot generate a valid R script to be source()d:
>>
>> \documentclass{article}
>> \begin{document}
>> Assign 1 to x: \Sexpr{x <- 1}
>> <<>>=
>> x + 1
>> @
>> \end{document}
>>
>> That is because the inline R code is not written to the R script
>> during the tangling process. When an R package vignette contains
>> inline R code expressions that have significant side effects, R CMD
>> check can fail because the tangled output is not correct. What I
>> showed here is only a trivial example, and I have seen two packages
>> that have more complicated scenarios than this. Anyway, the key thing
>> that I want to discuss here is, since the R code in the vignette has
>> been executed once during the weaving process, does it make much sense
>> to execute the code generated from the tangle function? In other
>> words, if the weaving process has succeeded, is it necessary to
>> source() the R script again?
>>
>> The two options here are:
>>
>> 1. Do not check the R code from vignettes;
>> 2. Or fix the tangle function so that it produces exactly what was
>> executed in the weaving process. If this is done, I'm back to my
>> previous question: does it make sense to run the code twice?
>>
>> To push this a little further, personally I do not quite appreciate
>> literate programming in R as two separate steps, namely weave and
>> tangle. In particular, I do not see the value of tangle, considering
>> Sweave() (or knitr::knit()) as the new "source()". Therefore
>> eventually I tend to just drop tangle, but perhaps I missed something
>> here, and I'd like to hear what other people think about it.
>>
>> Regards,
>> Yihui
>> --
>> Yihui Xie <xieyihui at gmail.com>
>> Web: http://yihui.name



[Rd] R CMD check for the R code from vignettes
Yihui Xie