similar to: Conventions: Use of globals and main 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 <csardi.gabor at gmail.com> wrote: 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

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 the script is organized into functions. Gabor On Sun, Aug 25, 2019 at 6:11 AM Cyclic Group Z_1 via

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, which may be mutated. Although this makes sense given R has historically been used interactively 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 very elegant, simple and consistent programming language too. That beeing said I think the main task

>?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 solution. It might also be that some functionality is put into functions to be reused in other places. This

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 Art of R Programming regarding this issue, this is mostly avoided by well-defined,

A very common use case for regmatches is to extract regex matches into a new column in a data.frame (or data.table, etc.) or otherwise use the extracted strings alongside the input. However, the default behavior is to drop empty matches, which results in mismatches in column length if reassignment is done without subsetting. For consistency with other R functions and compatibility with this use

I do think keeping the default behavior is desirable for backwards compatibility; my suggestion is not to change default behavior but to add an optional argument that allows a different behavior. Although this can be implemented in a user-defined function, retaining empty matches facilitates programmatic use, and seems to be something that should be available in base R. It is available, for

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

I think that's a good reason for not including this in regmatches; you're right, its name is somewhat suggestive of yielding matches. Also, that sounds like a great design for strcapture with an atomic prototype. Best, CG

Thank you, I am aware that there are packages that can accomplish this. I mentioned stringr::str_extract as a function that does not drop empty matches. I think that the behavior of regmatches(..., regexpr(...))?in base R should permit an option to prevent dropping of empty matches both for sake of consistency with the rest of the language (missing data does not yield a dropped index in other

Thank you! I greatly appreciate your consideration, though of course it is up to you. I think many people switch to stringr/stringi simply because functions in those packages have some consistent design choices, for example, they do not drop empty/missing matches, which facilitates array-based programming. For example, in the cases where one needs to make a new column in a data.frame (data.table,

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. Glattering name space might become a problem because you might end up having used all

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 potential anyways). On the other hand I am not sure what the main()-idiom would actually add to

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

Suppose one wanted to consider random variables X_1,...X_n and from each subtract off the piece which is correlated with the previous variables in the list. i.e. make new variables Z_i so that Z_1=X_1 and Z_i=X_i-cov(X_i,Z_1)Z_1/var(Z_1)-...- cov(X_i,Z__{i-1})Z__{i-1}/var(Z_{i-1}) I have code to do this but I keep getting a "non-conformable array" error in the line with the covariance.

I ran into an interesting issue today with ActiveRecord''s becomes method and discovered that it is mutating the receiver without me knowing it. The API docs<http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-becomes>say "The new instance will share a link to the same attributes as the original > class. So any change to the attributes in either

On Wed, Jun 8, 2016 at 8:14 PM, Xinliang David Li <davidxl at google.com> wrote: > > > On Wed, Jun 8, 2016 at 4:38 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Wed, Jun 8, 2016 at 12:31 PM, Xinliang David Li <davidxl at google.com> >> wrote: >> >>> >>> >>> On Wed, Jun 8, 2016 at 4:19 AM, Sean

Dear LLVM community, I am affiliated with the design and development of the Pony<http:/www.ponylang.org> programming language, which was recently published and has since been discussed on hacker news<https://news.ycombinator.com/item?id=9482483>, reddit [1]<http://www.reddit.com/r/ponylang>

Using a non-capturing group, "(?:...)" instead of "(...)", simplifies my example a bit > x <- c("Groucho <groucho at marx.com>", "<chico at marx.com>", "Harpo") > strcapture("([[:alpha:]]+)?(?: *<([[:alpha:]. ]+@[[:alpha:]. ]+)>)?", x, proto=data.frame(Name=character(), Address=character(),