R devel - Jul 2001 - Summary: too many arguments in foreign function call

OK, to summarize and clarify a bit

1) I downloaded some code that existed in "pure" FORTRAN,
FORTRAN+S-Plus,
and FORTRAN+R versions.  

2) I discovered that the primary difference between R and S-Plus version was
the use of a wrapper to reduce the number of arguments from 87 to 65.   When
I inquired why, the author of the code replied

	"R won't take more than 65 arguments to the FORTRAN code 
	(I have no idea why they would have this restriction, it
	seems ludicrous to me. Anyway, the 65 limit is why I combined 
	all those arguments (they were originally explicitly passed)."

He also noted that the 65 argument restriction is not present in Splus 5.

3) I posted a patch to change the limit on the number of parameters to .C,
.Fortran, and .Call from 65 to 255.  

4) I asked if this patch, or something like it would appear in the next
release of R because I wanted to create a package that used the exact same
(simpler) code for R and S-Plus.

5) There was a debate on the merit of using .Fortran to handle a large
number of arguments.  Most people suggested one of 

	- write a wrapper function Fortran C or that accepts some set of
arguments as a single 	vector and that calls the original Fortran function.

	- write a wrapper function using .Call or .External

Several reasons were put forth for *not* extending the number of permissible
arguments.  The core point seemed to be that there have been few reports of
problems with the restriction, and there is uncertainty about the maximum
number of arguments an operating system will support.

6) I still feel that it is a reasonable change to increase the number of
permitted arguments, at least to the same limits (whatever they are) imposed
by S-Plus.  This seems simpler than telling users that as soon as they hit
65 arguments they have to change their code or learn a new interface
mechanism.


-Greg



LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail by
anyone else is unauthorized. If you are not an addressee, any disclosure or
copying of the contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an addressee,
please inform the sender immediately.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

"Warnes, Gregory R" <gregory_r_warnes@groton.pfizer.com> writes:
> 6) I still feel that it is a reasonable change to increase the number of
> permitted arguments, at least to the same limits (whatever they are)
imposed
> by S-Plus.  This seems simpler than telling users that as soon as they hit
> 65 arguments they have to change their code or learn a new interface
> mechanism.
I think you missed one point that John was making: "N++". There has to
be a limit to the number of arguments, C does not allow you to code
anything else portably. Whatever limit we choose, someone is going to
bump into it sooner or later, and we can't just increase the limit
every time.  

Then there's the problem of portability between compilers. A little
Web search reveals that the minimum maximum number (sic) of arguments
that a C compiler may impose according to the C standard is 31. So
there may already be standards-compliant C compilers that cannot
compile R. Obviously none of those have appeared within our user
base...

That being said, I think 65 is a pretty weird limit to have. 2^N-1
would be a more obvious guess at a potential hard limit. So, since
we're already past 63, how about having a quick round of testing among
the R-devel readers to check out whether any of their systems would
break from inserting a limit of 127 or 255?

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

>That being said, I think 65 is a pretty weird limit to have. 2^N-1 
>would be a more obvious guess at a potential hard limit. So, since 
>we're already past 63, how about having a quick round of testing among 
>the R-devel readers to check out whether any of their systems would 
>break from inserting a limit of 127 or 255? 
I'd guess there are different ways this could fail.  

1. The compiler might have a hard-coded upper limit on the number of
arguments to a function.
2. It might have an upper limit on the number of bytes of code
generated in a function, or in an object file. 

With 255 as the upper limit, the functions do_dotcall and do_dotCode
in dotcode.c will both be huge, so they might trigger the second kind
of failure. (I'd guess that no 16 bit compiler could handle them, for
instance, but nobody is compiling R on one of those.) It's probably
worth putting together a new dotcode.c version for people to test, not
just ask them to test for the first kind of failure.

Duncan
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

> John M. Chambers <jmc@bell-labs.com> wrote:
>
[snip]
> 
> Empirical evidence is that the limit in S-Plus is 128. (The call 
> manyArgs(N) constructs a .C with N arguments to a C routine (with 200 
> arguments)). 
OK.  I've modifed my patch to bring R's limits to 128, the same as in
S-Plus,
as well as noting that this is the limit in Foreign.Rd.   I suppose that this 
limit is as good as any, and at least means that code written and tested with 
S-Plus won't have to be changed to work with R and vice versa (at least for 
this reason). 

The patch has been uploaded to 
ftp://cran.r-project.org/incoming/dotcall_128.gz

(I hope this will make it into R-1.3.1)

-Greg
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._