[Rd] [R] help with read.table() function

[Duncan Murdoch]

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.