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
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
And believe me this is not someting "totally orthogonal" to gretl's
future development. There can be important secondary and tertiary
effects that we can or cannot foresee right now.
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--