5 ms·
RegExp Lookbehind Assertions
- vmorgulis 11y ago> Yang Guo, Regular Expression Engineer Interesting and specialized job :-)
- hashseed 11y agoTo clarify, this is not a real job title. Chrome and V8 blog posts are written by engineers who worked on the feature being blogged about, and can choose a funky title to go with the name :)
- danso 11y agoWow, I didn't even know there was a different way to implement lookbehinds in such a way that variable-length patterns were even allowed: > Generally, there are two ways to implement lookbehind assertions. Perl, for example, requires lookbehind patterns to have a fixed length. That means that quantifiers such as or + are not allowed. This way, the regular expression engine can step back by that fixed length, and match the lookbehind the exact same way as it would match a lookahead, from the stepped back position.* > The regular expression engine in the .NET framework takes a different approach. Instead of needing to know how many characters the lookbehind pattern will match, it simply matches the lookbehind pattern backwards, while reading characters against the normal read direction. This means that the lookbehind pattern can take advantage of the full regular expression syntax and match patterns of arbitrary length. > Clearly, the second option is more powerful than the first. That is why the V8 team, and the TC39 champions for this feature, have agreed that JavaScript should adopt the more expressive version, even though its implementation is slightly more complex. regular-expressions.info has roughly the same explanation here: http://www.regular-expressions.info/lookaround.html http://www.regular-expressions.info/lookaround.html I guess I had just assumed that if even Perl didn't implement variable-length lookbehinds, then the performance or implementation cost must have been severe enough to justify leaving out such useful flexibility. What is the tradeoff that .NET and now JavaScript are willing to make? edit: According to a comment in the posted article, Perl 6 now implements variable-length lookbehinds http://www.perl6.org/archive/rfc/72.html http://www.perl6.org/archive/rfc/72.html
- peteretep 11y ago20-odd years of Moore's law?
- hashseed 11y agoImplementing lookbehind by reading backwards is not more computationally expensive than reading forward. It adds some complexity to the regexp engine, yes, but that's manageable. There are some quirks vs. stepping back and reading forward, like the article already explains. I guess Perl initially just did not implement it this way, whatever the reason was.
- lolc 11y agoI wonder what code could profit from such a niche feature. I cannot even imagine a situation where I would want to use this.
- minitech 11y agoEver used \b? This is like that, but for other patterns. Very useful in many situations, like tokenizing (because you have to match on things the last match already consumed).
- lolc 11y agoMaybe I've used \b before, but I can't recall using regexes for tokenizing. They've either been too powerful or not powerful enough for my tokenizing needs.
- prohor 11y agoI usually use look ahead negation to make tests that string doesn't match regex.
- lolc 11y agoWhat do you mean by "usually"? What situation calls for this? I wonder why people seem to consider this a worthy addition where in my view it only serves to complicate the implementation. From what I see these additions become useful long past the point where using a regex was sensible in the first place.
- solipsism 11y agoI've used lookbehind assertions (and negative lookbehind assertions) many times. Most recently I used them to do some complex find/replaceing across a pretty large codebase. My editor supports regex, and I'm glad it does because it made the job easy. From what I see these additions become useful long past the point where using a regex was sensible in the first place. Regex stops being a sensible solution when your pattern starts getting overly complex. The fact that you use one of these features doesn't imply your pattern is overly complex. These are not complex features, they're easy to use, and often extremely useful. For example when straightforward find/replace doesn't cut it. What would you suggest, I take 10 minutes to write a Python script for what took me about 15 seconds in my editor's Find/Replace box?
- prohor 11y agoI use regex quite often and I'm happy we have it now more powerful in Chrome. Though, what is so painful in regex is all those flavors of it. I with it was standardized across all languages / implementations.