Native support for GNU R
Yves Breitmoser
to my knowledge, there is no native interface to GNU R in Perl 5.
Apparently, having such an interface saves some pain in statistical
analyses. My current solution to extend Perl towards R is to start
an R process, and to feed its stdin to produce the stuff I want. However,
starting R takes some time, communicating with it via pipes is not
perfectly user--friendly, and interpreting the results would be simplified
under a native interface, too. I guess there would be quite a number of
persons interested in an interface to a core of R functions, at least.
Of course, since R is written in C, an extension this way generally is
possible, but I like to communicate with R in R language.
Yves.
yv...@euv-ffo.de
parsers have been written for. As it appears to me, however, the languages
that you are mainly interested in are substitutes (competitors) to Perl.
Also, you might include languages that are complementary to Perl. I
figure, a particularly interesting complement would be GNU R. First, it
enhances the capabilities of Perl in the way its name suggests (being a
practical extracting and report language). Secondly, it is maintained by
an army of statisticians (and programmers) to comprise the
state--of--the--art techniques. And thirdly, it is published under the GPL
and written in C.
Native support for R (inside Perl 6) would be interesting for all persons
who have to conduct specific data analyses regularly (Perl would collect
the data and extract the items to be analyzed, R would analyze them, Perl
would report), for persons who have to conduct single analyses where the
data extraction is particularly demanding, and for persons who conduct
single analyses comprising huge numbers of tests which can abstracted
rather well.
Moreover, if I could wish something to be realized in Perl 6, it would be
native support for arithmetic vector/matrix operations, as provided by GNU
R (or, ideally, as in J and APL). I do not know, to which degree this is
already meant to be done, though.
Thanks for your work, anyway,
Yves.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aaron Sherman
> I read that you can provide support (in Perl 6) for most languages that
> parsers have been written for. As it appears to me, however, the languages
> that you are mainly interested in are substitutes (competitors) to Perl.
You're mistaken about a core item here. First off, Perl 6 may have
grammars for other language constructs, but trust me when I say that
that's not what you're thinking of here, and that probably won't be in
the core anyway (you can always write a grammar module and distribute it
yourself).
No, what you're thinking of is Parrot. Parrot is a language-neutral VM
for running high-level, dynamic languages and allowing them to
inter-operate at run-time. As such, all high-level, dynamic languages
are prospective candidates for Parrot front-ends, but here's the catch:
the Parrot folks aren't writing the front-ends. There might be some
overlap in developers for certain projects, but if you want Parrot
support for Q, L, R, Z, W or any other language then I recommend that
you go to the mailing list(s) for those languages and try to get some
interest going in targeting Parrot as a back-end. Of course, you could
always just write your own compiler that targets R, but one presumes
that if you were so inclined, you wouldn't be asking perl6-internals to
do it :-)
MrJoltCola
>On Wed, 2005-02-09 at 12:08, yv...@euv-ffo.de wrote:
> > I read that you can provide support (in Perl 6) for most languages that
> > parsers have been written for. As it appears to me, however, the
> languages
> > that you are mainly interested in are substitutes (competitors) to Perl.
>
>You're mistaken about a core item here. First off, Perl 6 may have
This is the reason we should have changed the list name to parrot-internals
years ago, or spawned a new one. Nowadays I'm not as interested
in the Perl6 language as I am the potential to run a lot of languages on a
common VM.
-Melvin