Re: [Gretl-devel] note on Rlib
Riccardo (Jack) Lucchetti wrote:
> Depending on the answer above, one can implement this by for
example
> a)- creating a function or a program that can automatically translate
> a gretl script to an R script and vice versa
> b)- making it possible to freely combine R functions with gretl
> functions in gretl scripts
> c)- making it possible to use R fully but within a well-defined
> boundary such as with a construct like
> begin R
> <R code>
> end R
>
>
Well, we've had (c) for a while, as the "foreign" command. For all I know,
people are quite happy with it and nothing tragic has happened so far.
The question of how to implement this new functionality in gretl is
really important!! We should weight the pros and cons of each approach,
in order not to end up with a badly specified interface. In the
following you will find my proposal:
I created the libr-functionality because I was unhappy with the foreign
blocks. When I was writing R code I had to write gretl stubs for every R
function, in order to be able to pass parameters and return from and
into R. The new libr interface now makes this obsolete.
I think that most of the time you don't want use directly a R function,
because some of the more complex functions return variable types which
won't be supported in the near future by gretl (lists, s4 objects). So I
think that in general we should not make all R functions avaiable to
gretl, as a lot cannot be used from within gretl.
In order to make these function usable from within gretl, you have to
define a wrapper function which converts the arguments and returns the
more simple datatypes that gretl understands.These wrappers should be
defined in a foreign block, using "language=libr". And to make them
accesible from within gretl, we could enhance the gretl.export()
routines. If gretl.export is called from within a foreign libr-block and
a function is supplied as argument, the programm will make this function
avaiable for gretl scripts. Example:
<script>
nulldata 10
foreign language=RLib
func1<-function(q) {
z=sum(q[1,])
invisible(z)
}
func2<-function(q) {
z=mean(q[1,])
invisible(z)
}
gretl.export(func1)
end foreign
scalar a=1
matrix qq=ones(2,2)
#the statement below will work
scalar b=func1(qq)
#func2 has not been exported->error
scalar b=func2(qq)
#the same is true for chose
scalar b=choose(2)
</script>
With this approach we won't pollute the gretl namespace. The foreign
blocks will be executed when the file is included, so you know straight
from the beginning if it runs.
Christoph