Re: [Rd] Inconsistency in for stringsAsFactors

From: hadley wickham <>
Date: Fri, 22 Jan 2010 07:45:55 -0600

On Fri, Jan 22, 2010 at 2:17 AM, Martin Maechler <> wrote:
>>>>>> "SM" == Stavros Macrakis <>
>>>>>>     on Thu, 21 Jan 2010 20:19:28 -0500 writes:
>    SM> I noticed that in, the stringsAsFactors argument
>    SM> defaults to TRUE, whereas in the other methods, it defaults to
>    SM> default.stringsAsFactors().
>    SM> The documentation and implementation agree on this, so this is not a bug.
>    SM> However, I was wondering if this disparity was intended or if it might be
>    SM> some sort of unintentional oversight.  If it is intentional, I wonder what
>    SM> the rationale is.
> Some of us (including me) have strongly argued on several
> occasions that  global options() settings should *not* have an effect

> on anything "computing" but just on "output"
> i.e. printing/graphing of R results.
> As it is currently, potentially R scripts and R functions may
> only work correctly for one setting of
>     options( stringsAsFactors = * )
> which is against all principles of functional programming.

A similar argument would also seem to apply to defaultPackages, deparse.max.lines, download.file.method, encoding, expressions, warn and na.action. There are plenty of functions in R that violate other principles of functional programming, so, by itself, this argument seems a little weak to me. There are obviously differences of opinion about this issue in R core, and it's unfortunate that the user has to be exposed to them through inconsistent function definitions.



______________________________________________ mailing list
Received on Fri 22 Jan 2010 - 13:48:59 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 22 Jan 2010 - 17:50:23 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive