From ihaka@stat.auckland.ac.nz  Wed Dec 17 22:51:06 1997
From: ihaka@stat.auckland.ac.nz (Ross Ihaka)
Date: Thu, 18 Dec 1997 11:51:06 +1300 (NZDT)
Subject: Development Plans
Message-ID: <199712172251.LAA26527@stat1.stat.auckland.ac.nz>

I thought that it might be useful (to myself as well as others) to
write down my current plans for working on R.  I have indexed things
by my (vague) feeling of priority.  If you think my priorities are
completely wrong, please feel free to set me straight :-).
As you can see, I am confining myself almost entirely to internal
tinkering - if someone would put another 24 hours into the day I'll
take a look at applications too.

	Ross


1. Revision Of The Graphics System

Paul Murrell and I (mostly Paul) are revising the R graphics system so
that it will allow multiple active devices, better hardcopy facilities
and more flexible plot layouts.
[Status: well under way].


2. Make The Source Tree More Gnu Compatible

This means having a target installation directory in mind, (probably
defaulting to /usr/local/lib/R-x.xx) in mind rather than building the
distribution in place.  This would make it reasonable to peel back one
level of directory structure. I.e. move the source of the current src
director up one level.  The "graphics" subdirectory would also disappear,
to be replaced by one or two bigger code chunks.
[Status: this and the Fortran change below are relatively simple to put
in place, but keeping the cvs history intact could be a problem]


3. Fortran Integration

Work on a real integration of Fortran into R.  This would mean
adapting the configuration procedures used by Octave to detect and
use Fortran.  As a consequence, the current duplication of C and
F77 sources would disappear.  It would also it possible to incorporate
a much richer set of numerical and other capabilities into R.
[Status: I have done some basic experiments and it looks pretty
easy to do]


4. Demand Loading Of Objects

This would be similar in spirit to Thomas Lumley's approach, but
would go on at a somewhat lower level and also allow selective
freeing of such objects when memory demands are high.  It would
also make it possible to think in terms of "attaching" directories
of objects.  (At attach time all the objects in a directory would
be registered as loadables, and loaded when required).
[Status: I have thought a bit about this.  It should be pretty simple
but no doubt there are a few undiscovered gotchas in there]


5. Change Internal Handling of Lists

Do a rewrite of the internal handing of lists so that they are
really generic vectors.  This will mean large volumes of fairly
flakey subsetting and mutation code can be removed.
[Status: It is important to get this done, but it will be a big task.
Almost everything will break during the switch]


6. Memory Management

Revisit the memory management system.  In particular, we need a better
way of storing strings, and of allowing the heap to grow, rather than
having everything allocated up front.
[Status: Preliminary wishful thinking ...]


7. Miscellaneous

Do something about namespace management.
Finish writing persp (and some other graphics primitives).
Implement missing functionality such as "aov" and "persp".                 
[Status: I have played with some of this]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


Development Plans
Ross Ihaka