Riccardo (Jack) Lucchetti schrieb:
On Mon, 6 Jul 2009, Allin Cottrell wrote:
> My first thought on this is to the same effect but a little
> simpler: we could mark off R functions (either built-in, or
> defined via "foreign" blocks within gretl) by using the prefix
> "R_". So if you wanted to invoke the R "choose" function
you'd
> have to invoke it as "R_choose(args)". (Internally, we'd see the
> "R_" and pass the remainder of the word to the new function
> get_R_function_by_name().)
I like this. The only possible problem I can see is parsing the string
correctly when a dot is there, as in R_as.matrix()
I'm glad you defined a proper namespace even before I had to intervene ;-)
(I was going to quote from the Python Zen
http://www.python.org/dev/peps/pep-0020/:
"Namespaces are one honking great idea -- let's do more of those!")
Speaking about dots, what about 'R.' instead of 'R_'? Just a matter of
taste of course, but seems more common in many languages and the
internet. And bearing in mind how difficult it is to meaningfully search
for 'R' (ever googled for some R command?), maybe the prefix 'libR.'
would be better.
>> (b) are there portability problems?
>
Again inspired from Python Zen ("Explicit is better than implicit."),
what about using some kind of "include" statement at the top of a gretl
script if it uses libR? That way the dependency is not buried and hidden
and the script wouldn't fail half-way through but would refuse to run
right from the start if R isn't present.
BTW, I don't know if it has been mentioned before, but for Windows
(although I currently don't use it) I actually get the feeling that
gretl might already have become the best and/or most user-friendly R
frontend around. Maybe even in general for all OSes.
thanks,
sven