Proposal for exact matching and matching at a position in RegExp
brendan at mozilla.com
Sat Feb 13 14:40:44 PST 2010
On Feb 13, 2010, at 12:14 AM, Steve L. wrote:
> \G and ^ become more dissimilar conceptually when \G is not used as
> the leading element. With or without /m, ^ can be thought of as a
> one-character lookbehind that doesn't need to know the current
> search position index. With something like /\d|\G\w/ or the
> contrived /(?=(x?))\1\G\w/ (equivalent to /(?>x?)\G\w/ or /\G[^
> \Wx]/), however, the regex pattern must be aware of its start
> position within the target string. I think this sort of mental model
> is commonly used, and it's because \G is harder to sync with this
> model that that I'm comfortable with introducing /y even though it
> ignores the prior art and greater flexibility of \G. But then,
> compatibility with other regex flavors is probably good enough
> reason to chose \G over /y.
Not clear, since ES3 deviated from Perl and will not reconverge. The
committee is not going to standardize any lastIndex or pos mapping per
target string and regex pair, I am pretty sure.
By starting from Perl 4 (my fault, it was 1997), then upgrading to
Perl 5 with differences due to the need to specify what was codified
quirkily only in perl source code, while also trying only in places to
deal with Unicode well, we have painted ourselves into a corner.
Perl 6 of course breaks compatibility utterly, and good for it.
Perhaps with enough string- and byte-buffer performance, the JS
library ecosystem can promulgate a new class, call it RegEx, which has
the best consensus API, and built-in RegExp can try to fade away.
Anyway, when adding /y, we reckoned it was better to keep being
different than to try \G and invite complaints that we weren't the
same as the "genetic parent", Perl. Mutation is a bitch, and we're
quite the red-headed stepchild now ;-).
More information about the es-discuss