FWIW, one could imagine introducing a helper function global();
global <- function(expr) { eval(substitute(expr), envir = globalenv(),
enclos = baseenv()) }
to make it explicit that any assignments (and evaluation in general)
take place in the global environment, e.g.
> local({ global(a <- 2) })
> a
[1] 2
That "looks" nicer than assign("a", 2, envir = globalenv()) and it's
safer than assuming a <<- 2 will "reach" the global environment.
/Henrik
On Tue, Aug 27, 2019 at 3:19 PM Abby Spurdle <spurdl...@gmail.com> wrote:
>
> > this appears to disagree with the software-engineering principle of
> > avoiding a mutating global state
>
> I disagree.
> In embedded systems engineering, for example, it's customary to use
> global variables to represent ports.
>
> Also, I note that the use of global variables, is similar to using pen
> and paper, to do mathematics and statistics.
> (Which is good).
> Whether that's consistent with software engineering principles or not,
> I don't know.
>
> However, I partly agree with you.
> Given that there's interest from various parties in running R in
> various ways, it may be good to document some of the options
> available.
>
> "Running R" (in "R Installation and Administration") links to
> "Appendix B Invoking R" (in "An Introduction to R").
> However, these sections do not cover the topics in this thread.
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
