5 ms·
I find that to be a much worse analogy! In your analogy the difference is in everything other than functionality (they all cool the room); here, the difference
by dataflow 3y ago
I find that to be a much worse analogy! In your analogy the difference is in everything other than functionality (they all cool the room); here, the difference is in the functionality -- re2 literally cannot match against some patterns. Moreover, writing more code around re2 to hack around its limitations is like constantly pumping water over a fan to improvise an evaporative AC unit, not like installing a window AC unit once and then being able to forget about the difference.
> Look-around is rarely critical functionality
I have to disagree; I've seen them be needed enough to find them critical. (more below)
> when you don't have the full flexibility that you would if you were using a regex from a programming language.
But that's exactly my point - the cases where you can work around it with a programming language is the rare case, not the common one. The only cases where I'd say lookarounds are non-critical are a fraction of those situations where the developer is the one hard-coding the regex. That might be the case if you're prototyping something like a lexer (where the user is the developer), but that's not the majority of cases. And in those cases, you can (and likely will) hard-code a faster implementation anyway.
The much more common cases I see are the regexes that can be specified at run time, where making user write code or jump through other hoops is something between painful and impossible. I feel you argued against your own point in reference to ripgrep, honestly -- because these are the 2 most common situations where I see regexes:
1. Find/replace in text editors. This is probably the most common use of regexes I see. Here, backreferences or lookarounds are absolutely necessary for some replacements.
2. File names/paths, in command-lines or configuration files or such. Lookarounds (and sometimes backreferences) are such a critical tool here. Imagine the difference between being able to write a negation like '^(?!.*/\.(cache|git|svn)/).*[Bb]urnt[Ss]ushi' vs. not being able to.
- burntsushi 3y ago> The much more common cases I see are the regexes that can be specified at run time That's essentially what I acknowledged: when the regex is the interface. From my point of view, my previous comment anticipated this critque already. The only real difference I can see is a disagreement about how common it is. We won't resolve that one. I've been using regexes for decades. The number of times I've used look-around or even back-references can be counted on one hand. I can't even remember the last time I used it at all.
- dataflow 3y ago> The number of times I've used look-around or even back-references can be counted on one hand. I'm shocked. What do you most commonly use regexes for? For me, I type them in my text editor find/replace more frequently than anything, and use backreferences there on a pretty regular basis.
- burntsushi 3y agoYes, I use regexes in vim all the time. Never use look-around or really much regex features beyond the basics. 99% of all searches are easily just literals. I also use regexes with ripgrep of course. ripgrep has features that standard grep doesn't have that typically mitigate the need for look-around, such as the `-r/--replace` flag. (I can't remember I when I last used `-P/--pcre2` in ripgrep for a reason that wasn't testing it.) Otherwise the rest of my regex use is in programs for a variety of tasks. Note that I'm the author of Rust's regex crate and of this regex benchmark: https://github.com/BurntSushi/rebar https://github.com/BurntSushi/rebar
- dataflow 3y agoYeah I know who you are, that's why I was shocked. That's why I'd have thought you leverage regexes more than other folks, not less! On my end I do this all the time. E.g., a very common regex search/replace I do over and over is something like removing duplicate lines, e.g. replacing "^(.*)\n\1\n" with "\1\n" repeatedly. (Obviously exact deduplication you can do a different way, but you can imagine variations on it that are case-specific, e.g. removing all lines or table fields that are prefixes of the following ones.) Of course I'm not claiming this is the majority of my searches (literals are obviously far more common like you said), but this kind of stuff comes up quite regularly, on perhaps a ~weekly basis if not more frequently. I'm very surprised you don't do transformations like these!
- burntsushi 3y agoFor that one in particular, nope. The only thing I can think of is when I'm trying to count occurrences of something, but that's just `sort | uniq -c`. I'll note that Discord also uses the regex crate for something to do with automod[1]. It would be interesting to ask their users how often they're annoyed by the lack of look-around or backreferences or some other fancy feature. Although in their case, the linear time guarantee is likely essential to exposing regex support in the first place. [1]: https://support.discord.com/hc/en-us/articles/10069840290711-Filter-Messages-Using-Regular-Expressions-Regex- https://support.discord.com/hc/en-us/articles/10069840290711...