On 28/06/2013 15:54, John Fox wrote:
Dear Duncan and Steve,
Since Steve's example raises it, I've never understood why it's legal to
change the built-in global "constants" in R, including T and F. That just
seems to me to set a trap for users. Why not treat these as reserved
symbols, like TRUE, Inf, etc.?
Because people wanted to use them as names of things. Maybe a T (not t)
statistic.
And BTW, you can change the value of T for yourself, but you will not
change it for any package code, including R itself, since the base
namespace is ahead of the workspace in namespace scoping. Because of
that, it is years since I have seen anyone actually trip themselves up
over this.
Best,
John
-----Original Message-----
From: r-help-boun...@r-project.org [mailto:r-help-bounces@r-
project.org] On Behalf Of Duncan Murdoch
Sent: Friday, June 28, 2013 9:40 AM
To: S Ellison
Cc: r-help@r-project.org
Subject: Re: [R] Lexical scoping is not what I expect
On 28/06/2013 9:28 AM, S Ellison wrote:
I too find R's lexical scoping rules straightforward.
However, I'd say that if your code relies on lexical
scoping to find something, you should probably rewrite your code.
Except of course that almost every function relies on lexical
scoping to some extent!
This could get messy, because a) that's true and b) it actually leads
to some genuine risks when 'globals' get redefined or masked*.
How about I amend the assertion to "if your code relies on lexical
scoping to find a variable you defined, you should probably rewrite
your code."
and leave it at that, subject to some common sense about whether you
know what you're doing?
That still isn't right, because users should feel free to define
functions and call them from their other functions.
I think who defined it isn't the issue, the issue is whether it might
change unexpectedly. The user owns globalenv(). The package author
owns the package namespace. So packages should almost never read or
write things directly from/to globalenv() (the user might change them),
but they can create their own private environments and write there.
Where it gets a little less clear is when the user writes a function.
I
would say functions should never write directly to globalenv(), but
it's
perfectly fine to reference constants there (like other functions
written by the user). Referencing things there that change is the
risky
thing.
Duncan Murdoch
Steve E
*Example
sin.deg <- function(deg) sin(deg * pi/180)
sin.deg(45)
[1] 0.7071068
#looks about right
pi <- 3.2 #Indiana General Assembly bill #247, 1897.
sin.deg(45)
[1] 0.7173561
#oops ...
*******************************************************************
This email and any attachments are confidential. Any
use...{{dropped:8}}
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-
guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-
guide.html
and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
