R help - Jan 2005 - New Year Wish List

Congrats to all those who have contributed to R over the
past year.  As with last year, for New Year I would like to
list the top 10 features I would like to see in R.   The first 
three are the most important.

1. Scripting

   With this feature it would be possible to call R like
   this as a filter:

	R -f myprog.R infile1.txt infile2.txt > outfile.txt
   or
	prog1 | R -f myprog.R | prog2

   making it convenient to replace many instances of
   awk/perl/batch with R.  This could also be used by R itself
   to eliminate dependence on perl and UNIX tools in the
   package building scripts.  There are workarounds already but
   we need something that works smoothly.  This also relates to
   the discussions on the mailing lists on streaming.

2. Package Building Tools 

   The future of R will increasingly depend on the breadth and
   quality of the libraries so its important to have good
   package building tools and make them solid on all platforms.
   This breaks down into:

	a. installation.  The package building tools could
	   themselves be a package and installing them should 
	   be as easy as installing any other package.  Dependence 
	   on other software should be minimized.  Rewrite R CMD 
	   scripts and texi2dvi in R.  Eliminate dependence on perl, 
	   UNIX tools and path.  

	b. use.  Fix problem with .Rbuildignore and, on
	   Windows, the generation of vignettes.  Moving this 
	   all to R would likely make it easier to use, too.  
	   Need a brief document that discusses the flow of 
 	   issuing the R CMD commands.

3. Naive datetime class.  

   The chron package already provides a naive (i.e. time zone
   free) date time class but we need something in the standard
   packages.  Fortunately, the addition of the Date class has 
   solved 80% of the problem here but the remainder still needs 
   to be addressed.

4. Sourceforge-like Support for Subprojects.

  This refers to groupware support for subproject development.   
  The Lua and Ruby communities have done this with LuaForge.net and
  RubyForge.org.

5. Change Log

   There needs to be a standardized format to communicate changes
   in packages.  

6. Bug Reporting

   Need to find better web-based bug reporting software.

7. User Requirements

   Some way of tracking user requirements, wishlist, etc. This is
   related to last point.  The key point here is that bug tracking 
   needs to be expanded into issue tracking including design issues, 
   features requests, etc.

8. Improve Visibility of Future Plans

   Despite high volume mailing lists there is very little discussion
   of the future of R.

9. \& Back Reference

   We have \1, \2, ... but no \&.

10. Miscellaneous Bugs.  

   a.  NextMethod.  NextMethod works inconsistently.  I have found 
       each time one uses it one must use trial and error to figure out
       which args will be passed or not. [1] 

   b.  Regexps \b and \B do not always work properly. [2]

References

[1]
https://www.stat.math.ethz.ch/pipermail/r-devel/2004-October/031150.html
https://www.stat.math.ethz.ch/pipermail/r-devel/2004-October/031155.html

[2]
https://www.stat.math.ethz.ch/pipermail/r-devel/2004-December/031580.html
https://www.stat.math.ethz.ch/pipermail/r-devel/2004-December/031610.html

Gabor Grothendieck wrote:
> Congrats to all those who have contributed to R over the
> past year.  As with last year, for New Year I would like to
> list the top 10 features I would like to see in R.   The first 
> three are the most important.
  My wish for R is some sort of timestamping on objects, so I know when 
they were created or modified.

  This would then enable the creation of a 'make'-like system in R, 
where the 'target' is some output of an analysis (eg the fit of a linear
model) and the dependencies are the input data.

  For a complex problem, you might have a target that depends on many 
other things, and you dont want to have to redo expensive operations (eg 
MCMC runs, large simulations) if nothing that they depend on has 
changed. The grand idea is to have a single specification of the problem 
(which would be an R object of class 'make' perhaps) and then you can 
just do make(foo) to do all the required code to get the result.

  This might be a very useful method for transferring analyses between 
people.

  I did have a hack at putting timestamps on R objects by mucking with 
the C code that created new objects, and adding an 
attribute('timestamp'). It superficially worked, but R started to fall 
to pieces since objects stopped being identical to copies of themselves. 
Oops. it clearly needs attaching at a lower level, but I'm not sure 
where or how much of a performance hit it might be.

  End of wishlist.

Baz

> 4. Sourceforge-like Support for Subprojects.
> 
>   This refers to groupware support for subproject development.
>   The Lua and Ruby communities have done this with LuaForge.net and
>   RubyForge.org.
I think both are powered by http://gforge.org/ - it probably wouldn't
be difficult to set up something similar for R.
> 6. Bug Reporting
> 
>    Need to find better web-based bug reporting software.
> 
> 7. User Requirements
> 
>    Some way of tracking user requirements, wishlist, etc. This is
>    related to last point.  The key point here is that bug tracking
>    needs to be expanded into issue tracking including design issues,
>    features requests, etc.
Since the R sources have moved to svn, an obvious candidate for this
would seem to be trac (http://edgewall.com/trac/), which provides
issue tracking and integrates very nicely with svn.  Its wiki-type
facilities could potentially be used for future planning as well.

Hadley