[Rd] .C() vs .Call() (was Re: R-devel and not R-help (was 'using "= matrix (...)" in .C calls')

[Tony Plate]

At Friday 02:17 AM 6/18/2004, Martin Maechler wrote:

>[snip]  Even though we (R core) would like to promote the use
>of .Call() as much as possible, for most R users, [snip]

Why does "R core" wish to promote the use of .Call() over .C()?

I see two advantages for .C():

(1) The interface is very straightforward and I don't need to go to the 
trouble of using R macros and extractor functions in my C or C++ code in 
order to get at the data -- the data is just passed in C vectors of 
standard types, and I can return data the same way.  This means my C code 
is simpler and consequently (on average) more maintainable and less prone 
to bugs.  For example, consider the C functions 'convolve' (to be called by 
.C()) and 'convolve2' (to be called by .Call()) that are in "Writing R 
Extensions".  I am more confident that I can write correctly the R code for 
type checking and coercion needed for the .C() call than I can write 
correctly the corresponding C code (for example, because then I need to 
think about things like stack imbalances in my calls to PROTECT/UNPROTECT).

(2) .C() functions are easier to port between different implementations of 
the S language.

Am I missing advantages to using .Call() when .C() would suffice?  (i.e., 
when the data that must be passed back and forth can be easily packed into 
vectors.)

-- Tony Plate