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

[Martin Maechler]

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


   .............................
   .............................