Dear list member, this thread as well as the first one started by Philippe about the usefulness of a GUI is interesting and overwhelming alike. IMHO, it wittnesses the greatness and superiority of R compared to other statistical programming environments and programs: the core team and all people involved with it. Everyday I am flabbergasted and amazed anew; learning new concepts, programming tricks, statistical methods I was unfamiliar with and much much more: kudos to all of you. Let me now toss in my two cents:
First cent: Comments about a GUI Although I use Emacs/ESS and R batch mode mostly, a GUI is beneficial in terms of teaching statistics and/or econometrics with R. This conclusion draws upon experience nine years back, while I was giving, beside econometric classes, computer labs at university. At that time we had only commercial products at hand: RATS, GAUSS and EViews. From a students perspective EViews (menu-driven) was the most convenient one. The econometric method comprehension and the interpretation of its application is of utmost importance. Hence, novices should concentrate on this to familiarise themselves with the subject. Most of the students got scared and distracted by learning a command driven programming language too, i.e. this was too much to swallow at one time. With other words: do not challenge novices to statistics/econometrics programmatically. A point mentioned by Phillipe in an earlier email too. Now given Rcmdr: I like its flexibility and that everybody can tailormade his own `version' by adding new menus and functionalities. So to speak, a very decent ground work has been provided by John Fox and I appreciate it alot. I can only speak for myself: I am currently writing an `urca' add-in to Rcmdr, such that the package is more amenable to novice users in a computer lab for example; that is: they do not have to worry about the correct syntax or what can be achieved with which function. In order to do so, two files are needed: one is an addendum to the menu's file and the other one contains the R functions to be executed within Rcmdr. It is at the leisure of the instructure to include these into Rcmdr. They can be shipped in the package's /inst directory, for example. This seems to be a feasible approach for other package maintainers working in different fields too. Or would such an approach be to simple? Second cent: help system As voiced in earlier emails in this thread the R documentation, contributed tutorials and the likes as well as the help facilities are indeed great. The only snag, is a lack of an `easy to find' approach to be taken. Surely there is help.search(), apropos, help.start() etc. etc. But what would be nice, would be something similar to `texdoctk' for LaTeX document retrieval. That is: categorise the manuals, package manuals, vignettes and other contributed docs with respect to the catergory they belong to. Well, the snag is: who does this labour intensive work? Hm, I am sceptic, but it might turn out that this is not a feasible approach to be taken, but maybe my second suggestion is: making greater use of \concepts and/or \keyword by providing a file for download on CRAN that contains the \concepts entries & the function & the package in which it is contained. One could then download this file and execute a `zgrep' on it, as could be done likewise with a contents file from an apt repository to find out which file is contained in which rpm. The advantage would be the decentralisation of the work. It does not take that long when each package maintainer utilises \concepts in his .Rd files. Once, a package is contributed to CRAN, one could scan the tarballs and extract the relevant information into the above mentioned file. Another advantage would be, that users would find functions of packages that are currently not in their search path, because the packages have not been installed. And not a few questions on this list are answered by: `This functionality is contained in package xyz'. Anyway, I will introduce \concepts within the next release of `urca'. Best Regards, Bernhard > > "Philippe Grosjean" <[EMAIL PROTECTED]> writes: > > > Peter, > > > > You don't need the ActiveState Tcl distribution to add > extensions. If you > > compile extensions yourself (and these extensions have a compatible > > license), then you have no problems... (well, almost! You > must make sure > > those extensions compile correctly on all supproted > platforms). This is > > exactly what I do in the tcltk2 package. > > Best, > > > > Philippe Grosjean > > I know, it's just that it feels silly that we cannot build on the fine > work of ActiveState. > > -- > O__ ---- Peter Dalgaard Blegdamsvej 3 > c/ /'_ --- Dept. of Biostatistics 2200 Cph. N > (*) \(*) -- University of Copenhagen Denmark Ph: > (+45) 35327918 > ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: > (+45) 35327907 > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html -------------------------------------------------------------------------------- The information contained herein is confidential and is inte...{{dropped}} ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html