Maybe this is a my personal taste: I do not like pseudo R code in the
form <<coxme-build>> inside a chunk, and I'm curious about why
you do
not use real R functions to do the job.
coxme <- function(formula, data, subset, blah blah ){
coxme_check_arguments(...)
coxme_build(...)
coxme_compute(...)
coxme_finish(...)
}
You can define these coxme_xxx functions later in the parent
environment. It is also easy for one function to call another, so the
recursion is natural. Compared to text-processing tricks, I prefer
well-defined functions.
Your idea of using a named list to store R code is what I used in the
knitr package (http://yihui.github.com/knitr/demo/reference/), e.g.
% empty here
<<chunk1, echo=TRUE>>@
% real code is defined here
<<chunk1, echo=FALSE>>rnorm(10)
@
The second chunk appears later, but when you weave the document, the
code rnorm(10) will also go to the first chunk since the label
'chunk1' will index the code from the second chunk.
Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Tue, Jan 24, 2012 at 1:50 PM, Terry Therneau <therneau at mayo.edu>
wrote:> Almost all of the coxme package and an increasing amount of the survival
> package are now written in noweb, i.e., .Rnw files. ?It would be nice to
> process these using the Sweave function + a special driver, which I can
> do using a modified version of Sweave. ?The primary change is to allow
> the following type of construction
>
> <<coxme>>
> coxme <- function(formula, data, subset, blah blah ?){
> ? <<coxme-check-arguments>>
> ? <<coxme-build>>
> ? <<coxme-compute>>
> ? <<coxme-finish>>
> }
> @
>
> where the parts referred to come later, and will themselves be made up
> of other parts. ?Since the point of this file is to document source
> code, the order in which chunks are defined is driven by "create a
> textbook" thoughts and won't match the final code order for R.
> The standard noweb driver only allows one level of recursion, and no
> references to things defined further down in the file.
>
> ?The primary change to the function simply breaks the main loop into
> two parts: first read through the all the lines and create a list of
> code chunks (some with names), then go through the list of chunks and
> call driver routines. ?There are a couple of other minor details, e.g. a
> precheck for infinite recursions, but no change to what is passed to the
> driver routines, nor to anything but the Sweave function itself.
>
> Primary question: who on the core team should I be holding this
> conversation with?
> Secondary: Testing level? ?I have a few vignettes but not many.
> ? ?I'll need a "noweb" package anyway to contain the drivers
-- should
> we just duplicate the modified Sweave under another name?
> ? ?Call the package "noweb", "Rnoweb", ...?
>
> And before someone asks: Roxygen is a completely different animal and
> doesn't address what I need. ?I have latex equations just above the
code
> that impliments them, an annotated graph of the call tree next to the
> section parsing a formula, etc. This is stuff that doesn't fit in
> comment lines. The text/code ratio is >1. ?On the other hand I've
> thought very little about integration of manual pages and description
> files with the code, issues which Roxygen addresses.
>
> Terry Therneau
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel