Re: [Gretl-devel] note on Rlib
On Mon, 6 Jul 2009, Allin Cottrell wrote:
> (a) what happens in case of a name clash? ...
Yes, indeed. I've been thinking about that too. The first point
to make is that trying to interpret a "word" as an R function name
is the "last resort" in genlex.c. So any built-in, or
user-defined, gretl function will mask an R function of the same
name.
> Perhaps we may wrap R function calls in an ad-hoc function, like
>
> <gretlscript>
> scalar c = R("choose(10,4)")
> </gretlscript>
My first thought on this is to the same effect but a little
simpler: we could mark off R functions (either built-in, or
defined via "foreign" blocks within gretl) by using the prefix
"R_". So if you wanted to invoke the R "choose" function you'd
have to invoke it as "R_choose(args)". (Internally, we'd see the
"R_" and pass the remainder of the word to the new function
get_R_function_by_name().)
I like this. The only possible problem I can see is parsing the string
correctly when a dot is there, as in R_as.matrix()
> (b) are there portability problems?
Yes, it does raise a portability issue. We do have some of those
already: for example, the gretl command "mpols" will work only if
gretl is linked against (the optional) libgmp. There's also the
business of the optional third-party programs TRAMO/SEATS and
X-12-ARIMA. At present the functionality of these programs is
available only via the GUI, but it probably should be available
via script.
True. And you can add LaTeX on top of that if you want. But you'll agree
the ones you mention are rather special cases: mpols is definitely not
something you'd normally use for regressions, and the TRAMO/SEATS-X12
stuff is hard to use inadvertently, so to speak. My concern was coming
from the idea that if you start mixing native and R functions in your
scripts, to the point when it's hard to tell them apart, as in your
choose() example, then one day you take your script to another machine
where R isn't installed and, bang!, your script is useless.
There are some other issues too.
[...]
I'm just saying that the libR approach is not a magic bullet for
saving on initialization costs.
Chris' work and yours have been splendid. Integration with R is now much,
much better than it was. Thanks!
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti