>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>>>> 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
