Proposal for exact matching and matching at a position in RegExp
brendan at mozilla.com
Tue Feb 16 13:45:53 PST 2010
On Feb 14, 2010, at 6:04 AM, Steve L. wrote:
> On Feb 14, 2010, at 1:40 AM, Brendan Eich wrote:
>>> 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.
> That seems a reasonable position for the committee to take. To be
> clear, are you suggesting that \G be ruled out, but leaving the door
> open for standardizing /y?
Yes, I think \G without full Perl compatibility is less desirable
than /y -- but I would want some solution here, and it should be on
the Harmony agenda.
Perhaps we need you to seed that agenda. Start a new thread to remind
us of your 95, or just 5 (I hope ;-), theses nailed to the ES3
>> 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
> That would be quite interesting to see, but since there are just a
> few, mostly tolerable design issues with the existing ES RegExp API,
> I can only envision a switch to a JS library over built-in RegExp
> being justified if the library included pretty much all the features
> of ES regexes and added significant new features including better
> Unicode support. In the near term, the resulting file size would
> pretty much assure low adoption in browser-land.
Yes, it's a long term hope, or possibly dream.
> Since I don't have much hope for a reasonable alternative to RegExp,
> I think it's important to continue looking at RegExp improvements
> for future ES versions. I have a laundry list of desired changes and
> additions, but the three things I'd like to see first are /x, /y,
> and atomic groups. But now I'm off topic again, so I'll just leave
> it there. :)
To fuel this fire (separate thread is fine, all your theses at once), /
x already caused ES4 headaches which Waldemar argued are insuperable,
to-do with semicolon insertion.
More information about the es-discuss