[R] Lexical scoping is not what I expect

[John Fox]

Dear Duncan,

I think that it's reasonable to make a distinction between symbols
representing functions and those representing built-in constants, even if,
as in the case of pi and T (and letters, etc.), the latter are technically
implemented as variables. 

Although it may be natural to use the variable T for temperature or F for an
F-value (or pi for what?), nothing fundamental is gained by the ability to
do so (one could use temp or fvalue or Pi), while in the case of a function,
one can consciously mask, e.g., the standard mean(). I'm not sure that it's
generally wise for users to redefine functions like mean(), but I can see a
use for the ability to do that.

Please don't feel the need to reply if you don't wish to -- this isn't in my
opinion an important issue.

Best,
 John

> -----Original Message-----
> From: Duncan Murdoch [mailto:murdoch.duncan at gmail.com]
> Sent: Friday, June 28, 2013 11:07 AM
> To: John Fox
> Cc: 'S Ellison'; r-help at r-project.org
> Subject: Re: [R] Lexical scoping is not what I expect
> 
> On 28/06/2013 10:54 AM, 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.?
> 
> If we weren't allowed to change T and F, would we be allowed to change
> other "constants", like functions mean or max? If we couldn't change
> anything defined in the base package, would we be allowed to change
> things defined in other packages like stats or utils or graphics?  I
> think it's simply a matter of setting the line somewhere, and R has
> chosen to set it in the most permissive place that's reasonable.  It
> assumes that its users know what they are doing.
> 
> Why not allow changes to TRUE or Inf?   TRUE is a constant, whereas T
> is
> a variable containing TRUE.  Inf is also a constant, corresponding to a
> length one vector containing that value.  Those are treated by the
> parser like 2 or "hello".  It would be really bad if someone could
> change the meaning of 2 (though I hear some old Fortran compilers
> allowed that), but is it really so bad to allow someone to define their
> own plot function, or temperature variable named T?
> 
> Duncan Murdoch
> >
> > Best,
> >   John
> >
> > > -----Original Message-----
> > > From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-
> > > project.org] On Behalf Of Duncan Murdoch
> > > Sent: Friday, June 28, 2013 9:40 AM
> > > To: S Ellison
> > > Cc: r-help at 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 at 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 at 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.
> >