[Bioc-devel] [biocore] Sweave changes (keep.source = TRUE or FALSE?)

Deepayan Sarkar deepayan.sarkar at gmail.com
Wed Dec 6 23:09:07 CET 2006

On 12/6/06, Friedrich Leisch <friedrich.leisch at stat.uni-muenchen.de> wrote:
> [ resent to bioc-devel upon request from Seth ]
> >>>>> On Tue, 5 Dec 2006 13:17:14 -0500 (EST),
> >>>>> Vincent Carey 525-2265 (VC5) wrote:
>   >>
>   >> Sorry to join in late, I was travelling last week. First, let me thank
>   >> Duncan for his work, this really fixes one of the main drawbacks
>   >> Sweave had!
>   >>
>   >> Hence, I agree with Duncan and Martin in that I would like to change
>   >> the default in R to keep.source=TRUE. But I understand Robert that
>   >> testing software gets hard if the tools which are used for testing
>   >> change.
>   > It seems to me that if you are changing the API/behavior then we users have
>   > to adapt to that, given sufficient warning.  This means that instead of
>   > Sweave("foo.Rnw"), I have to write Sweave("foo.Rnw", keep.source=FALSE),
>   > to get the former behavior, right?
> Or insert \SweaveOpts{keep.source=FALSE} in the vignette or set the
> global default for R via options() or whatever -> that is yet to be
> implemented and one of the goals of this discussion is to see what is
> the best way in terms of least work for developers.
>   > It may still be debatable whether keep.source=TRUE is a desirable default.
>   > It does propagate comments, but Sweave is supporting literate programming,
>   > so that comments in code are not necessarily crucial for the objective
>   > of the Sweave user.  The document narrative is supposed to take care
>   > of commenting.  It is also not clear to me that keeping the source
>   > formatting is preferable to the programmatic formatting by the interpreter
>   > display facility.
>   > So I would say there are real questions about the suitability of
>   > keep.source=TRUE as a default for Sweave.  The availability is
>   > definitely nice, but the spirit and aesthetic aspects of Sweave
>   > use may be better supported in many cases, perhaps the vast
>   > majority of all documents created to date, with keep.source=FALSE.
> I agree on the comments part, i.e., that comments in code chunks
> should not be so much necessary as in standard R code. One exception
> is inside function definitions where the can be very usefull.
> Ad source formatting: If you use a smart editor with automatic
> indentation etc then human formatting is better than what the machine
> does in many cases (depends on the human, of course).

I think that's a big "if", and it relates to Wolfgang and Vince's
point: does it really make sense to make keep.source=TRUE the default?
Once upon a time, I would have agreed with you that the parse-deparse
behaviour is less desirable, but now I'm not so sure. Prof Ripley
addresses this point in this post from a year ago:


where he in particular quotes section 3.1 (Tidying R code) of the
'Writing R Extensions' manual:

   This tidied version is much easier to read, not least by other users
   who are used to the standard format.

I think this applies all the more to Sweave documents, which are by
nature intended to be read by others.

There's another issue which no one has raised, which is that of
wrapping. With keep.source=TRUE, there's no check that lines don't get
too long (not that deparse does that great a job at it, but at least
it's something). Do we really want a default where there is no such
check? To me, it seems that one of the major points of a LaTeX-like
typesetting system is automatic formatting by default.

Of course, I would personally use keep.source=TRUE in all my
documents, because I do use a smart editor with automatic indentation,
and I have the relevant snippets from

http://cran.r-project.org/doc/manuals/R-ints.html#R-coding-standards and

in my .emacs file. However, anyone with similar coding practices is
also likely to be sophisticated enough to know to put a \SweaveOpts{}
line on top of his or her .Rnw files. I don't think the same can be
said of more casual R coders.



More information about the Bioc-devel mailing list