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.dun...@gmail.com] > Sent: Friday, June 28, 2013 11:07 AM > To: John Fox > Cc: 'S Ellison'; r-help@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-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.