-*- mode: indented-text;-*-        
This file, ideas.txt, is to be maintained as plain ASCII, for expedience.

It contains brief sketches of items that might be considered for
inclusion in R, and provides a spot for adding comments and
elaborating on earlier ideas. 


			    THE R IDEAS LIST

		      Dream, dream, dream ...
				- The Everly Brothers

***********
3D GRAPHICS
***********

    It would be nice to have something more sophisticated than "persp"
    for plotting surfaces. It would be nice to have contour labels and
    labels on persp plots, first!

****************
DYNAMIC GRAPHICS
****************

    Statistics for the video game generation ...  We need to move to
    an event-based model for this.

**********
GAM MODELS
**********

    The basic code is at STATLIB. However, this is unreliable code
    (also under S), and we might want to start from scratch.

    (Gu's gss looks like a good alternative)

*******
MAPPING
*******

    We have the Becker/Wilks sources for constructing map data bases.
    All we really need is the drawing code.

**********
DATA ENTRY
**********

    Current version is quite primitive. Need at least better factor
    entry mechanism and the ability to delete rows and columns.

    In the Tcl/Tk world it looks very tempting to try a
    reimplementation using the table widget

***********
MENU SYSTEM
***********

    Some way of adding user-definable menus. GraphApp, Gnome, and
    Tcl/Tk all point in that general direction.  

    The Tcl/Tk stubs are in place, but we need an overall plan. Would
    it suffice to have a free-floating toolbar mechanism, or do we
    want to reinvent the console and have an integrated window-top
    toolbar? 

**********
DATA FILES
**********

    File reading: We might want a mechanism for reading "ragged" files
    i.e. with varying number of fields per line (Excel exports
    those...)  read.table(...,fill.na=T) ?

    Some advanced method for generating data frames from input files.
    One idea is to elaborate on the fact that when data() loads a .R
    file, it changes to the data directory, and quite flexible input
    specs can be obtained by having the R file  contain 
        xxx<-transform(read.table("something.txt",
             ...), ...). 
    Extending that idea, one could have the convention that a
    <file>.Rsp file is a specification for <file>.txt. With a little
    bit of thought, one might avoid the ugliness of the transform and
    read.table calls.

    Foreign database formats (www.wotsit.org)

    Should .RData be renamed to something user-visible?

    XML

************************
FORMULA BASED INTERFACES
************************

    The interfaces to various standard tests are inconsistent, e.g.
    wilcox.test takes two vectors, but kruskal.test a vector and a
    grouping factor. We probably want to keep this for compatibility
    with S-PLUS, but we'd like to have a consistent interface using
    model formulas too. This also includes looking at plot.formula
    which has trouble with pch=vector, and making sure that there's
    also points.formula, etc. (Kurt + Peter plan to work on this)

****
MISC
****
    (some very petite stuff can go in here)

    bug.report dumps user into vi, which he might not know...

    Better summaries of multi-df effects (extend summary.lm)

    Successive diffs contrast (MASS has contr.sdif)

    Choleski with pivoting 

    Change defaults for X11? (pointsize and the scaling for multiframe
    layouts) 

    Add BuildInfo tags to package descriptions.