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

From: Martin Maechler <maechler_at_stat.math.ethz.ch>
Date: Mon 30 Jan 2006 - 09:16:41 GMT

>>>>> "Duncan" == Duncan Murdoch <murdoch@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

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

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Mon Jan 30 20:22:04 2006

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:40 GMT