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

[Martin Maechler]

>>>>> "Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>     on Mon, 30 Jan 2006 09:58:23 -0500 writes:

    Duncan> 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.

    Duncan> I'd say "a way to use R", and I think teachers
    Duncan> *should* present such a use.  It insulates users
    Duncan> from uninteresting details, just as now it's
    Duncan> probably good to advocate using file.choose() rather
    Duncan> than explaining paths and escape characters before
    Duncan> beginners can do anything with data.  Later on
    Duncan> they'll need to learn those things, but not from the
    Duncan> 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.

    Duncan> Right, I agree here too.  This would soften the
    Duncan> shock of the 1st introduction, but as soon as the
    Duncan> students are ready to look at functions and
    Duncan> understand default parameters, they'd be able to see
    Duncan> that the default value for the "file" argument is
    Duncan> file.choose().  They might become curious about it
    Duncan> and call it by itself and discover that it is
    Duncan> possible to program GUI elements (assuming that
    Duncan> 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.

    Duncan> I think I disagree with you because I think GUI
    Duncan> programming is programming.  I don't want beginners
    Duncan> to think that there are two kinds of programs:
    Duncan> command-line programs that they can write, and GUI
    Duncan> programs that only Microsoft can write.  I want them
    Duncan> to think that programming is programming.  Doing
    Duncan> complex things is harder than doing easy things, but
    Duncan> it's not qualitatively different.

Actually, I completely agree with what you said here.

However we disagree to some extent about the implications
(on teaching R, learning R, ..) of making GUI elements defaults
for basic R functions.  
Also the phrase  "consistent as a programming language"  was
about the fact that for some functions, the default file(name) would be
GUI-dispatching whereas for other functions it would not (and
you agreed it should not).

Martin

    Duncan> 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 with read.table would be
    Duncan> unfortunate, but no worse 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.