"Doc, it hurts when I do this."
"So, don't do that."

If no one in R Core does anything about this issue (in terms of changing Sweave or Stangle), then the solution still remains very simple. Authors of vignettes should avoid using anything in \Sexpr{} that has a side effect. As long as they do that, the code will tangle correctly and produce the same result as Sweave.

R CMD check already detects other things which may or may not be outright errors but are viewed as bad practice. I think it is bad practice to put code with side effects into an Sexpr. So, I don't do that. If I did do that accidentally, I really wouldn't mind if R CMD check warned me abut it.

  -- Kevin

On 6/2/2014 6:28 PM, Gavin Simpson wrote:
On 2 June 2014 15:59, Duncan Murdoch <murdoch.dun...@gmail.com> wrote:

On 03/06/2014, 4:12 AM, Gavin Simpson wrote:

On 2 June 2014 11:44, Duncan Murdoch <murdoch.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>> wrote:

....
     Several of us have told you the real harm:  it means that users
     can't easily extract a script that replicates the computations done
     in the vignette.  That's a useful thing to be able to do.


Isn't the issue here that `tangle()` doesn't, currently, "extract a
script that replicates the computations done in the vignette", but
rather does so only partially?

No, I think the issue is that some people don't want to have to guarantee
that the tangled source produces the same results.  R doesn't guarantee it,
it is up to the author to do so.

I think those issues have become conflated on this thread; R CMD check
issues raised the problem that side effects in \Sexpr may lead to tangle()
generating an R script that may not work or do so only incorrectly.

Whatever the ensuing discussion; the above issue is not ideal and as you
mention below it could be solved by not allowing side effects in \Sexpr,
fixing tangle so that \Sexpr is recorded, or some other workaround.


People seem to be arguing across one another throughout this thread.
Yihui has identified an infelicity in the tangle implementation. Turning
off tangling + sourcing in R CMD check may not be a desirable solution,
so if the aim is to extract R code to replicate the computations in the
vignette, tangle() needs to be modified to allow for inclusion
(optional) of \Sexpr "chunks".

That's one solution, and the other is to limit \Sexpr code to things with
no side effects, as Sweave was originally designed.

That would be perfectly fine also; clarifying usage etc helps and whilst it
may inconvenience those authors that exploited the ambiguity, there is a
solution now that anyone can write their own vignette drivers.



To move this thread forwards, would contributions that added this
optional feature to tangle() be considered by R Core? If so, perhaps
those affected by the current infelicity might wish to propose patches
to the R sources which implement a solution?

As I said before, I'm more sympathetic to that solution than to dropping
the requirement that tangled code should work.  I think the changes to base
R need only be minimal:  only an extra argument to the driver code for the
tangling.  Users who want to use this feature should write their own (or
use someone else's if they don't' mind an extra dependency) as a
"non-Sweave vignette driver", whose implementation is to call Stangle with
the non-default parameter setting.

Duncan Murdoch

I agree, and given that the changes to base R would be minimal and yet
solve the problem for those wanting to allow & tangle side effects in
\Sexpr (or allow them to solve it with a driver) it is disappointing to
note i) the length of this thread (!) and ii) the often irrelevant
arguments that some contributors have offered. (Do note this is not
directed specifically at you Duncan.)

It has not gone without notice of late the increasing regularity with which
threads here descend into irrelevant or antagonistic directions.

G


______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to