On Tue, 7 Jul 2009, chris wrote:
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.
Yup, I think we're all agreed on that.
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.
Yes, it's very nice to be able to send inputs, and grab output,
directly.
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)...
True, but I don't see any harm in exposing things like "choose"
and other such relatively simple built-ins.
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...
That's certainly worth thinking about. We'll have to come back to
this.
Allin.