From tlumley at u.washington.edu  Mon Dec 18 18:13:34 2006
From: tlumley at u.washington.edu (Thomas Lumley)
Date: Mon, 18 Dec 2006 09:13:34 -0800 (PST)
Subject: [Rd] capturing value of C or Fortran function
In-Reply-To: <Pine.LNX.4.61.0612121713100.15075@enigma.local>
References: <Pine.LNX.4.61.0612121713100.15075@enigma.local>
Message-ID: <Pine.LNX.4.64.0612180835110.30197@homer22.u.washington.edu>

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



[Rd] capturing value of C or Fortran function
Thomas Lumley