[Rcpp-devel] macros RCPP_FUNCTION_...,

Romain Francois romain at r-enthusiasts.com
Tue Jun 18 21:05:45 CEST 2013


Le 18/06/13 19:50, Dirk Eddelbuettel a écrit :
>
> On 18 June 2013 at 16:26, Romain Francois wrote:
> | Hello,
> |
> | Who is using the macros RCPP_FUNCTION_0, ..., RCPP_FUNCTION_65, ...
> | (i.e. all the macros that live in the preprocessor_generated.h file).
> |
> | Their functionality is superseded by a much better way of doing it
> | (modules).
> |
> | I'd like to drop them at some point.
> |
> | Obviously it is not happening overnight, because for starters our own
> | RProtoBuf uses them. But I will update RProtoBuf so that it does not.
> | There is also uses in the RcppGSL vignette which I will update.
> |
> |
> |
> | The file spans >6000 lines of generated code that we could do without.
> | To put this into context, this represents about 10% of the lines of the
> | .h files in Rcpp.
> |
> | I don't think many people are using it, and I don't blame them. This was
> | an interesting idea when we introduced it, but we have something better now.
>
> Hm, I think my preference would be for a rather long period of deprecation --
> at least a year if not more -- before declaring it defunct.

For what it is worth. I just downloaded and unpacked source code for 113 
packages using Rcpp, using a modified version of your runRcppDepends.

Then:

romain at naxos /tmp/stuff $ grep -r RCPP_FUNCTION *
RcppGSL/vignettes/RcppGSL/RcppGSL-intro.Rnw:% RCPP_FUNCTION_1( int, 
sum_gsl_vector_int, RcppGSL::vector<int> vec){
RcppGSL/vignettes/RcppGSL/RcppGSL-intro.Rnw:% RCPP_FUNCTION_1( double, 
gsl_vector_sum_2, Rcpp::List data ){
minqa/ChangeLog:	* src/minqa.cpp: Expand RCPP_FUNCTION_X macros to make 
debugging

So apart from:
- some vignette code that can easily be replaced by something using // 
[[Rcpp::export]] and be much easier to understand.
- some comment in  minqa

No one uses it.

Doing a long deprecating period over something nobody uses or care about 
is a good way to forget to do it.

OTOH, removing them deals with the issue right now. We might get -ve 
feedback from people who are in fact using it. In which case we can 
propose to either
- fix their code using something simpler, easier to understand, better
- let them include the 6600 lines of clutter

Again, this code was a good idea when we made it, not anymore.

> Even then, maybe we should consider to not remove them as we have a good
> tradition of maintaining public APIs going forward. So my suggestion would be
> to deactivate them behind an #if with a new configuration #define in
> RcppConfig.

This is more clutter, we have to document this defined.

> APIs are contracts we have with users.  I would prefer to see strong reasons
> for change, rather than a style preference.

This was just me stumbling upon the code and going: we don't need this 
stuff anymore, let's get it out of the way.

If we keep it we surely need to document it as part of this contract you 
mention.

> Now, 10% of code is of course a pretty good reason, but is it really making
> that much of a difference?  The Rcpp package is large, and will remain large
> either way.  An added #define should make compilaton faster which is good.
>
> Other views?
>
> Dirk

This is an opportunity for a quick diet. Just before the summer.

Of course it will stay big, see
http://gallery.r-enthusiasts.com/graph/Evolution_of_Rcpp_code_size_165

Anyway, too much time wasted already writing this email, but I remain 
confident we can do something about that. We even managed to get the 
classic api out of the way after all.



-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30

R Graph Gallery: http://gallery.r-enthusiasts.com

blog:            http://blog.r-enthusiasts.com
|- http://bit.ly/Zs97qg  : highlight 0.4.1
`- http://bit.ly/10X94UM : Mobile version of the graph gallery



More information about the Rcpp-devel mailing list