[Rd] Wish list

[Byron Ellis]

On Jan 1, 2006, at 7:36 AM, Duncan Temple Lang wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> 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.
>>
>
> We have been thinking of this, for me in the context
> of putting R on small sensor network nodes.

This was recently done with CLISP by, essentially cat'ing the image  
onto the end of the CLISP executable. You could probably do the same  
with an Rda and a startup script (since R isn't truly image based) on  
a small custom front end that links the DLL. You'd need to patch save  
and load, but you'd be able to deliver executable apps (assuming base  
and everything is installed). For a completely self-contained  
executable (i.e. not requiring an installer) you'd probably want to  
build a "minimal" R that you can just source in or load as an image  
(or we could just go to images in general.... R's been sort of  
meandering in that direction for the last couple of years ;-) )


>
>> 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.
>>
>
> This has been in the works for a long time and I still dislike two
> small pieces of the solution that make it limited.
>
>
>> 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.
>
> Yes not that hard to do given the work in other interfaces,
> but I wish the Windows users would contribute it.

No, with the DCOM stuff it should be pretty straightforward these  
days. We actually did a bit of this with I think it was R 1.1 or so  
before the Bioconductor project got started. Security was an issue as  
Duncan M. pointed out as I recall. You could basically remotely trash  
someone's drive, no good. In the end, I think you can do what you  
need to do with the DCOM interface and everything else you can do  
with a front-end. Being able to hook into .Net/Mono would be useful I  
think. On the Very Cool list would be a "managed" version of R, but  
that falls into the Things That Don't Result In Degrees so its on  
indefinite hold (it does give Naras and I something to talk about at  
coffee though).

>
>>
>> 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.
>>
>> 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.

Many handhelds are simply too limited. Those that aren't are usually  
Linux based and its just a matter of cross-compiling. Unfortunately a  
lot of the chips are not really suitable for floating point work.  
Additionally, a lot of the very limited PDAs (e.g. Coldfire-based  
PDAs) don't have an MMU.

>>
>> 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.
>>
>> 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.
>
> There is some work in progress on an extensible, R-based
> package mechanism.
>
>>
>> 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.
>>
>
> Well, there has been work on this that people couldn't agree on.
>
>
> And while we are on the topic of wishlists...
> Generally (i.e. not directed specifically to Gabor),
> the suggestions are very welcome, but so are contributions.
> And for issues such as making the existing R available on handhelds,
> that is a programming task. And I draw a large distinction between
> programming and creative research which is based on new concepts and
> paradigms.  The pool of people working in statistical computing  
> research
> is very small. And to a large extent, their time is consumed with
> programming - making the same thing work on multiple platforms,
> correcting documentation, etc. which are good things, but
> not obviously the best use of available research ability and time.
> There are many more topics that are in progress that represent
> changes to what we can do  rather than just to how we do the same  
> thing.
>
> One of the reasons S (R and S-Plus) is where it is now
> is because in Bell Labs, the idea was to be thinking
> 5 years ahead and both meeting and directing the needs for the future.
> Because of R's popularity (somewhat related to it being free),  
> there is
> an aspect of development that focuses more on software for  
> statisticians
> to use "right now".
> Obviously, th development is a mixture of both the current and the
> future, but there is less of the future and certainly less of the
> longer term directions that is sacrificed by the need to maintain an
> existing system and be backward-compatible.
> If statistics is to fulfill its potential in this modern IT, we  
> need new
> ideas and research into those new ideas. If we focus on basic
> programming tasks (however complex) and demand usability above  
> concepts,
> we risk losing those whose primary focus is in statistical computing
> research from the field.
>
> While R provides statisticians and stat. comp. researchers with a
> terrific vehicle for doing their respective work, it also acts as
> a constraint for doing anything even moderately new. But much (not  
> all)
> of R is based on innovations from the 1970's, 80's and 90's.   And
> as IT evolves at a terrific pace, to keep up with it, we need to be
> forward looking.
>
>
> I'll leave it there - for the moment - and go fight off the ants
> that are invading my desk!  While I wrote this down relatively

Yes, Winter (such as it is around here) has arrived hasn't it? :-)

> rapidly, the ideas have been brewing for a long time. If anyone
> wishes to comment on the theme, I hope they will take a few minutes
> to think about the broad set of issues and tradeoffs.
>
>
>   D.
>
>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> - --
> Duncan Temple Lang                    duncan at wald.ucdavis.edu
> Department of Statistics              work:  (530) 752-4782
> 4210 Mathematical Sciences Building   fax:   (530) 752-7099
> One Shields Ave.
> University of California at Davis
> Davis,
> CA 95616,
> USA
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
>
> iD8DBQFDt/by9p/Jzwa2QP4RAr6UAJ4mT9C1JcGwlFFJRFVDteyetDrAjACfax7B
> 0MpswqQE442j23WzJjqUADA=
> =Aq8t
> -----END PGP SIGNATURE-----
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian