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(a)univpm.it
http://www.econ.univpm.it/lucchetti