[Rd] Conventions: Use of globals and main functions

Duncan Murdoch murdoch@dunc@n @end|ng |rom gm@||@com
Mon Aug 26 20:19:36 CEST 2019


On 26/08/2019 1:58 p.m., William Dunlap wrote:
> Duncan Murdoch wrote:
>  > Scripts are for throwaways, not for anything worth keeping.
> 
> I totally agree and have a tangentially relevant question about the <<- 
> operator.  Currently 'name <<- value' means to look up the environment 
> stack until you find 'name'  and (a) if you find 'name' in some frame 
> bind it to a new value in that frame and (b) if you do not find it make 
> a new entry for it in .GlobalEnv.
> 
> Should R deprecate the second part of that and give an error if 'name' 
> is not already present in the environment stack?  This would catch 
> misspelling errors in functions that collect results from recursive 
> calls.  E.g.,

I like that suggestion.  Package tests have been complaining about 
packages writing to .GlobalEnv for a while now, so there probably aren't 
many instances of b) in CRAN packages; that change might be relatively 
painless.

Duncan Murdoch

> 
> collectStrings <- function(list) {
>      strings <- character() # to be populated by .collect
>      .collect <- function(x) {
>          if (is.list(x)) {
>              lapply(x, .collect)
>          } else if (is.character(x)) {
>              strings <<- c(strings, x)
>          }
>          misspelledStrings <<- c(strings, names(x)) # oops, would like 
> to be told about this error
>          NULL
>      }
>      .collect(list)
>      strings
> }
> 
> This gives the incorrect:
>  > collectStrings(list(i="One", ii=list(a=1, b="Two")))
> [1] "One" "Two"
>  > misspelledStrings
> [1] "One" "Two" "i"   "ii"
> 
> instead of what we would get if 'misspelledStrings' were 'strings'.
>  > collectStrings(list(i="One", ii=list(a=1, b="Two")))
> [1] "One" "Two" "a"   "b"   "i"   "ii"
> 
> If someone really wanted to assign into .GlobalEnv the assign() function 
> is available.
> 
> In S '<<-' only had meaning (b) and R added meaning (a).  Perhaps it is 
> time to drop meaning (b).  We could start by triggering a warning about 
> it if some environment variable were set, as is being done for 
> non-scalar && and ||.
> 
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com <http://tibco.com>
> 
> 
> On Sun, Aug 25, 2019 at 5:09 PM Duncan Murdoch <murdoch.duncan using gmail.com 
> <mailto:murdoch.duncan using gmail.com>> wrote:
> 
>     On 25/08/2019 7:09 p.m., Cyclic Group Z_1 wrote:
>      >
>      >
>      > This is a fair point; structuring functions into packages is
>     probably ultimately the gold standard for code organization in R.
>     However, lexical scoping in R is really not much different than in
>     other languages, such as Python, in which use of main functions and
>     defining other named functions outside of main are encouraged. For
>     example, in Scheme, from which R derives its scoping rules, the
>     community generally organizes code with almost exclusively functions
>     and few non-function global variables at top level. The common use
>     of globals in R seems to be mostly a consequence of historical
>     interactive use and, relatedly, an inherited practice from S.
>      >
>      > It is true, though, that since anonymous functions (such as in
>     lapply) play a large part in idiomatic R code, as you put it,
>     "[l]exical scoping means that all of the problems of global
>     variables are available to writers who use main()." Nevertheless,
>     using a main function with other functions defined outside it seems
>     like a good quick alternative that offers similar advantages to
>     making a package when functions are tightly coupled to the script
>     and the project may not be large or generalizable enough to warrant
>     making a package.
>      >
> 
>     I think the idea that making a package is too hard is just wrong.
>     Packages in R have lots of requirements, but nowadays there are tools
>     that make them easy.  Eleven years ago at UseR in Dortmund I wrote a
>     package during a 45 minute presentation, and things are much easier now.
> 
>     If you make a complex project without putting most of the code into a
>     package, you don't have something that you will be able to modify in a
>     year or two, because you won't have proper documentation.
> 
>     Scripts are for throwaways, not for anything worth keeping.
> 
>     Duncan Murdoch
> 
>     ______________________________________________
>     R-devel using r-project.org <mailto:R-devel using r-project.org> mailing list
>     https://stat.ethz.ch/mailman/listinfo/r-devel
>



More information about the R-devel mailing list