Re: [Rd] Feature request: non-dropping regmatches/strextract

That sounds great! Thank you for your consideration. Best, CG __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Feature request: non-dropping regmatches/strextract

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 __ R-devel@r-project.org mail

Re: [Rd] Feature request: non-dropping regmatches/strextract

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 p

Re: [Rd] Feature request: non-dropping regmatches/strextract

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

Re: [Rd] Conventions: Use of globals and main functions

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

Re: [Rd] Conventions: Use of globals and main functions

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

Re: [Rd] Conventions: Use of globals and main functions

> 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

Re: [Rd] Conventions: Use of globals and main functions

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

Re: [Rd] Conventions: Use of globals and main functions

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

Re: [Rd] Conventions: Use of globals and main functions

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

Re: [Rd] Conventions: Use of globals and main functions

ostly 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

[Rd] Conventions: Use of globals and main functions

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 hist

Re: [Rd] Feature request: non-dropping regmatches/strextract

Using strcapture seems like a great workaround for use cases of this kind, at least in base R. I agree as well that filling with NA for regmatches(..., gregexpr(...)) makes less sense, given the outputs are lists and thus are retained in the list.  Also, I suppose in the meantime the stringr pac

Re: [Rd] Feature request: non-dropping regmatches/strextract

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 pr

[Rd] Feature request: non-dropping regmatches/strextract

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 reassignme