>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> >>>>> on Sun, 29 Jan 2006 16:35:50 -0500 writes:
Duncan> On 1/29/2006 1:29 PM, Prof Brian Ripley wrote: >> On Sun, 29 Jan 2006, Marc Schwartz wrote: >> >>> I would argue against this. >>> >>> If this were the default, that is requiring user >>> interaction, it would break a fair amount of code that I >>> (and I am sure a lot of others have) where automation is >>> critical. >> I don't see how. The current default is >> >>> read.table() >> Error in read.table() : argument "file" is missing, with >> no default >> >> so the only change is that the default might do something >> useful. >> >> Nor do I see the change would help, as the same people >> would still use a character string for 'file' and not >> omit the argument. (It seems very unlikely that they >> would read any documentation that suggested things had >> changed.) Duncan> No, but people teaching new users (or answering Duncan> R-help questions) would have a simpler answer: just Duncan> use read.table(). but I am not sure that people teaching R should advocate such a read.table; I they did, the new R users would get the concept that this is the way how to use R. I still think R should eventually be used for "Programming with Data" rather than a GUI for ``clicking results together''. Hence users should be taught (in the 2nd or 3rd part, not the 1st one of their introduction to R) to work with R scripts, writing functions etc. And similar to Marc, I would never want default behavior to start up a GUI elements: It is also much more error-prone; just consider the "choose CRAN mirror" GUI that we had recently introduced, and the many questions and "bug" reports it produced. I know that I am biased in my views here; but I strongly advocate the "useRs becoming programmeRs" theme and hence rather keep R consistent as a programming language, partly agreeing with Gabor here. >> The same issue could be made over scan(), where the >> current default is useful. Duncan> scan() is very useful for small reads, and rarely Duncan> needed for reading big formatted files, {people might disagree with this; given scan() is more efficient for large files; but that's not really the topic here.} Duncan> so I wouldn't propose to change it. good. Duncan> The inconsistency Duncan> with read.table would be unfortunate, but no worse Duncan> than the current one. >>> A lot of the issues seem to be user errors, file >>> permission errors, hidden extensions as is pointed out >>> below and related issues. If there is a legitimate bug >>> in R resulting in these issues, then let's patch >>> that. However, I don't think that I can recall >>> reproducible situations where a bug in R is the root >>> cause of these problems. >> Nor I. >> >> Note that file.choose does not protect you against file >> permission issues (actually, on a command-line Unix-alike >> it does nothing much useful at all): >> >>> readLines(file.choose()) >> Enter file name: errs.txt Duncan> No, it's not helpful here, but again it makes things Duncan> no worse, and there's always the possibility that Duncan> someone would improve file.choose(). I strongly prefer the current usage read.table(file.choose(), ....) which implicitly ``explains'' how the file name is chosen to a new default read.table( .....) I'd like basic R functions not to call menu(), GUI... parts unless it's really the main task of that function. Martin ............................. ............................. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel