On 1/1/2006 8:47 AM, Gabor Grothendieck wrote:
> This is my New Year wishlist for R features. One
> common thread is that I find I sometimes use languages
> other than R including javascript, Windows batch and
> gawk. Others have mentioned other languages too. It
> would be nice if, in those cases I could use R
> simplifying development into a single environment
> (viz. R).
>
> The following are not in any order.
>
> 1. Self Contained Executables
>
> Make it possible to create self contained R
> executables. Something like tcl starkits
> http://www.equi4.com/starkit.html
> or Python py2exe
> http://starship.python.net/crew/theller/py2exe
> is what I am thinking of. Its ok if they
> are interpreted as long as its all transparent.
How self-contained? It would be relatively easy to create small
executables that could make use of the DLLs in R_HOME. But that's
probably not useful if better support for your next suggestion was
there. If you want something that would run on a machine with no R
installed, that probably involves changing the linking scheme (at least
in Windows), and would not be so simple.
> 2. R as a Filter
>
> Support using R as a filter analogously to
> awk/gawk. e.g.
>
> echo a x 3 | R -f myprog.R | findstr /i answer
> echo a x 3 | R -e "chartr('x', 'X', readLines(STDIN()))" | findstr /i X
>
> This would allow replacement of certain awk/gawk
> filters with R. In the above STDIN or some
> would refer to the echo output, not to further
> input from the script. I think /dev/stdin
> can already be used in UNIX but not in Windows.
>
> 3. Microsoft Active Scripting Language
>
> Make R into a Microsoft Active Scripting
> language. Nearly every other major scripting
> language including perl, python, ruby, tcl,
> oorexx, vbscript, jscript and others have
> Microsoft Active Scripting support. This would
> allow R to be used like javascript in HTML files
> in Microsoft environments and also in any other
> software that supports Microsoft's active
> scripting interface.
R is not designed to be secure. I think this would be a very risky
thing to do.
>
> 4. Extend Clipboard Support to Non-Text Objects on
> Windows
>
> If one selects and copies a table in Internet
> Explorer (IE) one can then paste it into Excel and
> it comes out as expected with one Excel cell per
> IE table cell. However, R does not currently
> support this level of integration. (Current
> workaround is to paste it into Excel and then copy
> it back out of Excel. Excel will add tabs to the
> text that is so copied.)
>
> I understand that this feature may be in R 2.3.0
> but am mentioning it for completeness.
Yes, I wrote some functions to do some of this, but I haven't committed
them to the trunk. I didn't like the user interface much: using
clipboard support depends heavily on being able to handle the various
clipboard format constants (CF_BITMAP, etc.), and R doesn't handle
constants well. I'll take another look at them and see if I get any
inspiration on how to make them palatable.
> 5. Handhelds
>
> Version(s) of R for handheld computers such as
> Palm, Windows Mobile, Symbian, Blackberry, etc.
> UNIX-based handhelds would likely be simplest
> but the others would likely be useful to a wider
> audience.
All this needs is someone who wants to gather/create the tools and start
building the binaries.
> 6. Issue Tracking in Packages
>
> Standard method of tracking issues in CRAN
> packages. Provide svn and Trac support or
> equivalent to CRAN package authors or at least
> have a common change log mechanism. There is
> currently no uniform way of finding out what has
> changed in a package.
>
> 7. system
>
> The arguments of "system(...)" should be extended
> in various operating systems so that a consistent
> set is available across them. Right now it works
> differently under Windows and UNIX.
>
> 8. Extend Grid to Base Graphics
>
> Rework base graphics so that they use grid
> graphics underneath to the extent possible or else
> leave them as is but have a version or package
> that emulate them using grid graphics.
This sounds like the gridBase package.
> 9. Eliminate Perl
>
> Get rid of all use of perl within R. The parts
> of R that use perl have not changed much probably
> because its too onerous to have to deal with a
> complex multilanguage setup. Eliminating perl might
> speed up improvements in those areas. This mostly
> affects the package buildin gprocess which could
> then be rehosted within R as a package building
> package.
> 10. Event Loop
>
> Add an event loop mechanism to facilitate GUI
> programming in R and also to facilitate the development
> of facilities to allow higher levels of interaction
> within grid graphics.
There is such a thing now: see the Writing R Extensions manual. It
still needs work, but people using it and suggesting improvements will help.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
