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 _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel