[Rd] Script editor for Windows GUI

[Luke Tierney]

On Thu, 26 Feb 2004, Simon Urbanek wrote:

> On Feb 26, 2004, at 11:58 AM, Marsland, John wrote:
> 
> > Is you project based upon the SJava package, because we have had lots 
> > of
> > problems with the callback interface?
> 
> No, we are not using SJava for obvious reasons. I tried hard to fix it, 
> but for some platforms that is impossible w/o complete rewrite, so we 
> use our own interface now. The Java GUI approach has the advantage that 
> it also circumvents the event loop problems in that context.
> 
> > Would you consider releasing your work in progress under the GPL? We 
> > are
> > keen to avoid re-inventing things and its a long time until we are all 
> > at
> > UseR! - we could at the very least give some user feedback.
> 
> I think this is a good idea, especially given the feedback I got since 
> the post :P. I'll talk to others in the developer team and maybe we 
> could leak a developer preview pre-pre-pre-alpha release in the next 
> weeks for those interested.
> 
> > On a slightly different tack, I have recently taken a look at Jython - 
> > an
> > implementation of Python in Java that produces byte code that runs on 
> > the
> > JVM. Combined with this there is a project called xoltar which aims to 
> > bring
> > functional programming to Python. This got me thinking that a R parser 
> > could
> > be written in Java for a core set of functionality allowing code and
> > packages written in "pure-R" to be compiled as byte code and run on 
> > the JVM.
> > Then one could call  the SJava package from Java to execute anything 
> > unusual
> > in R proper.... any thoughts?
> 
> Good question - due to the amount of packages that use C/Fortran code I 
> had the impression that this sounds just too crazy. But I'm really keen 
> on getting some feedback on this, because technically, one of the CS 
> students here would enjoy doing something like that ...

I think it's doable but a very big task.  Python had a head start
because Python has always been byte compiled to its own set of byte
codes.  This means the semantics evolved in a way that is more
supportive of compilation (things like being able to reliably identify
which variables are local, no lazy evaluation, etc.).  In addition
what seems to constitute the Python C core seems to be smaller than
the R core, the bits in base+nmath, say, by about a factor of 5.
Overall I think it would probably be about an order of magnitude
harder to get R to a state comparable to Jython.  That is before
starting to worry about packages needed to do anything useful.  You
can read about what was involved in creating Jython and do the math
yourself....

Once we get the R byte code compiler fully operational things may
eventually become easier since we may be able to the move some things
now done in C out into R where they are easier to maintain and could
then be automatically handled by an appropriate compiler back end.
Getting to a pure Java or pure .NET/mono setting is still likely to be
a fairly dauting task for a while.

Best,

luke

-- 
Luke Tierney
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
   Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu