help with read.table() function
On 1/30/2006 4:16 AM, Martin Maechler wrote:
"Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca>
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'd say "a way to use R", and I think teachers *should* present such a use. It insulates users from uninteresting details, just as now it's probably good to advocate using file.choose() rather than explaining paths and escape characters before beginners can do anything with data. Later on they'll need to learn those things, but not from the beginning.
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.
Right, I agree here too. This would soften the shock of the 1st introduction, but as soon as the students are ready to look at functions and understand default parameters, they'd be able to see that the default value for the "file" argument is file.choose(). They might become curious about it and call it by itself and discover that it is possible to program GUI elements (assuming that file.choose() calls one).
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.
I think I disagree with you because I think GUI programming is programming. I don't want beginners to think that there are two kinds of programs: command-line programs that they can write, and GUI programs that only Microsoft can write. I want them to think that programming is programming. Doing complex things is harder than doing easy things, but it's not qualitatively different. Duncan Murdoch
>> 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.