Contexts

[romainfrancois]

Do we need some sort of context concept, i.e. a context gives a particular meaning to an attribute.

The obvious example is that Rcpp::export does not trigger the same things when sourceCpp'ing a single file or contributing to compileAttribute'ing a set of files in a package.

So perhaps we could have a sourceCpp and compileAttributes contexts, or perhaps file and package.

[kevinushey]

Thinking out loud, compileAttributes and sourceCpp each offer their own interpretation of a set of attributes (// [[Rcpp::export]], // [[Rcpp::depends]], // [[Rcpp::interfaces]]). Perhaps, rather than tying each attribute to a function, we should define handlers for (groups of) attributes.

Users could register their own handlers for attributes of a certain form. So, they write a function like:

fooHandler <- handler( list("foo"), function(attributes) {
    ...
})

For packages, that handler could be called by another function (probably compileAttributes), and would ensure that all attributes called foo are passed in to that function. Then, R code defined is run to process those attributes in some fashion. Perhaps the handlers would all be defined in an attributes.R file or something like that. This would also allow users to reuse, or extend, attributes to some extent, by adding in their own handlers for the same attributes.

I think package developers will still want all processing of attributes wrapped into a compileAttributes() call; this call will have to:

1. Read and parse the attributes in all of .c / .cpp files,
2. Identify all the attributes handlers necessary,
3. Run these attributes handlers, passing in the necessary attributes + information for them to do their job.

Just some ideas.

[romainfrancois]

What if we were to leverage the R package some more, i.e. sourceCpp were to create a temp package and load it.

The advantage of that is that sourceCpp can then just call compileAttributes and so we only have to implement compileAttributes. This way handlers are handed e.g. the root directory of the package and the attribute.

This makes compileAttributes the work horse, then sourceCpp can:

• create a skeleton
• copy original C++ code in the src directory
• call compileAttributes to generate additional code and content (e.g. in the NAMESPACE, DESCRIPTION, ...)
• do a R CMD INSTALL into a temp library and load the package.

I think this is the way to go. @kevinushey ?

[kevinushey]

This sounds like a great idea. This could also provide a mechanism for users to have their compiled sourceCpp code persist across sessions (e.g. by specifying the library by hand). I could imagine some users making 'ad-hoc' libraries of sourceCpped code when prototyping and such.

[romainfrancois]

One problem is that this sort of has to go through R CMD INSTALL which is kind of slow. One alternative could be to use devtools::load_all but this will use Rcpp to compile the attributes and this is not controllable. Perhaps I can later negociate something with hadley.

[jjallaire]

Believe it or not devtools::load_all actually calls R CMD INSTALL so it wouldn't be any faster.

One issue related to this approach is that it would break some existing sourceCpp code. This is because sourceCpp works by appending the generated code to the source file (thus picking up all typedefs and includes) whereas compileAttributes works in a fresh source file (no typedefs, includes only as directed by inline plugins, etc.).

[romainfrancois]

Thanks for the clarification. Must admit I did not go deep into load_all code.

And that's a very good point. Perhaps this means back on the original idea of having different behavior for the same attribute depending on whether we do sourceCpp or compileAttributes.