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'. 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. Of course, existing code naming an argument with "VALUE" would break, so a completely new interface, perhaps .C.function(), .Fortran.function(), would be required to avoid that. Has this facility been ruled out?
capturing value of C or Fortran function
3 messages · Harris A. Jaffee, Hin-Tak Leung, Thomas Lumley
Well, fortran subroutines don't really have return values (versus fortran functions, which do - as far as I know that's the only difference between fortran subroutines and functions). There is also a somewhat sticky matter, of C routines that returns fairly complex types, like pointers, strings... and likewise, fortran functions can return rather complex things, like matrices, etc. It is going to be difficult to do a one-size-fit-all solution. So all you are trying to cater for, is a rather small subset of C/fortran functions which returns a single int or a single double? (anything to do with arrays you'll need to "smuggle" the array size out the old-fashion way via argument pointers).
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'. 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. Of course, existing code naming an argument with "VALUE" would break, so a completely new interface, perhaps .C.function(), .Fortran.function(), would be required to avoid that. Has this facility been ruled out?
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
4 days later
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