[Gretl-devel] note on Rlib

Riccardo (Jack) Lucchetti r.lucchetti at univpm.it
Tue Jul 7 08:57:47 EDT 2009


On Tue, 7 Jul 2009, Talha Yalta wrote:

>> No-one is forcing anyone to use R from within gretl. But you'll agree with
>> me that having the possibility of interacting in the smoothest possible way
>> with R is
>>
>> 1) nice to have: hey, this is free software; if R is better than gretl at
>> something, why not use it?
>> 2) cool, as gretl does R, but R doesn't do gretl :-) 3) attractive for
>> people who like R but would like a friendlier environment
>> 4) totally orthogonal to gretl's future development plans.
>>
>> So I can't see what the downside is.
> I agree with the above points. I also agree with the concerns that you
> expressed regarding function names and portability. All I am saying
> deciding on how to integrate R with gretl is an important decision and
> requires a policy on whether using R within gretl is
> a)- someting nice to have
> b)- encouraged
> c)- nice to have but in fact discouraged

I don't really think we need a policy here. Even from a political 
standpoint (which is not my primary concern anyway), we're not even mixing 
licences, since both gretl and R are GPL. There may be gretl users who 
don't even know what R is, people who use it sporadically (like myself), 
others who may use gretl just as an R frontend. Again, I can't see any 
problem with any of these attitudes. In my view, gretl's aim should be to 
make applied econometrics as practical and efficient as possible. If this 
involves borrowing stuff from other projects, so be it. Let me remind that 
we've been doing this forever, internally (gretl's source is full of stuff 
adapted from R, netlib, gnumeric etcetera). It's called "division of 
labour" :-)

The only drawback to this idea is that encapsulating code from other 
projects may be so impractical to outweigh the benefits. I had a 
conversation recently with Christian Brownlees, the author of dynamo 
(http://dynamo.sourceforge.net/), who argued that he'd like to integrate 
dynamo into gretl, but that implies a dependency on libgsl, which is not 
on our agenda, at least in the short term (see 
http://lists.wfu.edu/pipermail/gretl-users/2009-June/003351.html). But in 
principle cooperation between projects is IMHO the way to go.

> 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.


Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

r.lucchetti at univpm.it
http://www.econ.univpm.it/lucchetti


More information about the Gretl-devel mailing list