Interesting to hear the chatter about knitr today. Related to this is the
desire to evaluate Sweave, knitr, etc reports incrementally and
interactively. It is of course currently possible to evaluate the *body* of
a block, but what about the other parameters of the block with side
effects? This is essentially a generalization of the report generator to
the notion of "annotated code blocks".

My primary use case is interactive data analysis using a literate
programming document instead of a simple script. This is often a convenient
way to work, because it's easy to record thoughts, plans, observations and
the code in a single document, and then the final result can be generated
as a report. The analysis itself is an iterative and interactive process,
so continually regenerating a report, even with caching, is not very
efficient or convenient.

Here are some concrete benefits:

Figure files could be generated outside of the report generation, i.e.,
when fig=TRUE. I am constantly having to write pdf()/dev.off() around by
code blocks. Utilities like ggsave() help a little in some cases, but using
the code block name to name the figure automatically would be even more
convenient.

Caching support, as implemented by knitr or Seth's weaver package, could be
useful for saving intermediate results, for either passing to a colleague
or for resuming later.

The extensibility of knitr opens up additional possibilities.

These annotated meta blocks effectively separate the accidental issues of
saving and distributing results from the analysis itself. What do you guys
think? Are code blocks only for generating reports, or could we use them in
other ways?

Michael

	[[alternative HTML version deleted]]