I meant that using a script both as a script and a library (sourcing into other
files to serve as a package) is bad practice. I don't think having any
functions in a script is necessarily bad practice.
Best,
CG
__
R-devel@r-project.org mailing list
ht
The point is, that there are several possible problems.
But.
One the one hand they are not really problematic in my opinion (I do not
care if my function has potential access to objects outside of its
environment because this access is read-only at worst and it's not common
practice to use this p
I appreciate the well-thought-out comments.
To your first point, I am not sure what "glattering" means precisely (a Google
search revealed nothing useful), but I assume it means something to the effect
of overfilling the main namespace with too many names. Per Norm Matloff's
counterpoint in The
Firtst, I think that thinking about best practice advise and beeing able to
accomandate different usage scenarios is a good thing despite me arguing
against introducing the main()-idiom.
Let's have another turn on the global-environment is bad argument.
It has two parts:
(1) Glattering namespace
> That beeing said I think the main task of scripts is to get things done via
>running them end to end in a fresh session. Now, it very well may happen that
>a lot of stuff has to be done. Than splitting up scripts into subscripts and
>sourcing them from a meta script is a straightforward soluti
Definitely, I agree that global variables have a place in programming. They
play an especially important role in low-level software, such as embedded
programming, as you mentioned, and systems programming. I generally would
disagree with anyone that says global variables should never be used, an
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) })
> "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.
Sorry, I made a mistake.
It is in the documentation (B.4 Scripting with R)
e.g.
(excerpts only)
R CMD BATCH "--a
> 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
Hey,
I always found it a strength of R compared to many other langaugas that
simple things (running a script, doing something interactive, writing a
function, using lambdas, installing packages, getting help, ...) are very
very simple.
R is a commandline statistics program that happens to be a ve
> Duncan Murdoch
> on Mon, 26 Aug 2019 14:19:36 -0400 writes:
> 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
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 fin
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
Right, I did not mean to imply these tests are equivalent. Only that both
similarly exclude execution of main() under some context.
Best,
CG
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
That is unfortunately wrong, though. Whether the script runs as "main"
and whether R is in interactive mode are independent properties. I
guess most of the time it works, because _usually_ you run the whole
script (main()) in non-interactive mode, and source() it in
interactive mode, but this is no
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
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
This seems like a nice idiom; I've seen others use if(!interactive()){
main() }to a similar effect.
Best,CG
On Sunday, August 25, 2019, 01:16:06 AM CDT, Gábor Csárdi
wrote:
This is what I usually put in scripts:
if (is.null(sys.calls())) {
main()
}
This is mostly equiv
On 25/08/2019 12:08 a.m., Cyclic Group Z_1 via R-devel wrote:
In R scripts (as opposed to packages), even in reproducible scripts, it seems
fairly conventional to use the global workspace as a sort of main function, and
thus R scripts often populate the global environment with many variables, w
This is what I usually put in scripts:
if (is.null(sys.calls())) {
main()
}
This is mostly equivalent to the Python idiom. It the script runs from
Rscript, then it will run main(). It also lets you source() the
script, and debug its functions, test them, etc. It works best if all
the code in th
20 matches
Mail list logo
