On Wed, 13 Dec 2006, Harris A. Jaffee wrote: > Re: src/main/dotcode.c:do_dotCode() > > The value, if there is one, of a function called by .C or .Fortran is not > captured, so one needs a wrapper. To avoid that, the user would have to > declare that there is a value, specify its type, and supply an R variable > to hold the value. Presumably, all of these could be combined in a new > "VALUE=var" parameter. Then do_dotCode could arrange the correct type of > C variable to receive the value (for every one of the 66 possible instances > of the call), and then transfer that value to 'var'.
Ick. There is no way (I hope) that .C() is going to stop being a pure function and go and write in other variables > It seems doable with > a strong enough macro, if a bit complicated. Or one could say VALUE=<type> > and get the value as a new, (n+1)_th element of the current list value. AFAICS this is possible only for a predefined list of return types. Even worse "vector of 4 ints" and "vector of 5 ints" count as different types, since it is not possible for do_dotCode to work out how much memory is pointed to by a pointer. It seems a lot of extra code for very little extra generality. If someone submitted a patch that also carefully documented that there was no slowdown for .C/.Fortran and no loss of ANSI C conformance it might be considered, but I can't predict any great enthusiasm for it. -thomas ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel