Proposal for exact matching and matching at a position in RegExp

Steve L. steves_list at hotmail.com
Wed Mar 3 23:44:25 PST 2010


Chopping up your replies a bit...

On March 03, 2010 10:28 AM, Andy Chu wrote:

> I agree that Perl has useful stuff that JavaScript doesn't have.  But
> it's a slippery slope because even Perl 6 has admitted that Perl 5
> regexes got out of hand. [...]
> It's a hard problem, because adding power and keeping compatibility
> and keeping sane syntax are all at odds with each other. [...]
> I think focusing on use cases is the important thing.

Yes, I tend to agree with this, along with your other related points, 
generally. But I believe Perl 6's radical redesign (or any other dramatic 
RegExp changes that would be similarly disruptive) have already been ruled 
out for ES. So we're stuck with RegExp (which isn't all that bad really--at 
least it has cross-language familiarity going for it), and therefore I'd 
rather see it improve than stagnate and perpetuate its problems. The great 
thing is, if you want to add new features, other regex flavors offer an 
abundance of options to consider.

> Agree that we should take it on a case-by-case basis.  In this case it
> sounds like /y, which has nothing to do with Perl, is good.  (If I
> were to nitpick I would say /y for "sticky" is silly, I would call it
> /a or /n for "anchored")

I believe the y actually comes from "yylex". ES4 proposals had originally 
called for the corresponding property to be named anchored or nosearch 
before changing it to sticky to avoid overloading the term anchored (which 
is commonly used to describe regexes starting with ^ or ending with $) and 
to better fit with the letter y. If the name changed to anchored, I'd prefer 
/a over /n. Flag n (as in "(?n)") is already used by .NET for the 
ExplicitCapture option, which is a feature that might be worth considering 
for ES6+. I don't mind "sticky", personally.

>> Heh. :-) I've posted half of a response at
>> http://blog.stevenlevithan.com/archives/fixing-javascript-regexp , and
>> within the next couple weeks I'll try to follow up on es-discuss with a
>> write-up that excludes the less realistic change proposals from that page
>> and adds suggested new features (including /y). I'm very interested in
>> which
>> proposals from that page you think are most likely to gain any traction,
>> and
>> which might not be worth raising for serious consideration.
>
> I looked it over again.  All of it seems good to me, except:
>
> 1) The 2 things about backreferences.  I haven't really run into these
> personally so I guess I'm agnostic.  But the arguments about why
> they're not bad for compatibility aren't super compelling.  I guess I
> question whether enough people have run into it to justify the
> potential breakage.

Although I definitely appreciate the feedback, I disagree about both the
compatibility impact (it would be nice to have some hard data/evidence about 
this, of course) and the value of fixing ES's backreference specification 
bugs.

> (If it's really a goal to create an entirely new RegEx (no p) class,
> those things could be addressed there.  Although I think that proposal
> is problematic too since it is a burden on implementers to have 1.5
> regex implementations.)

Regarding "RegEx", I'm pretty certain Brendan was talking about a
hypothetical new library (name unimportant) that the JavaScript community
might create in the future. I don't think anyone has suggested adding a
second regular expression class to the ES spec itself (and anyone who wanted 
to do so without getting ignored or laughed at had better have some damn 
compelling justification). Perhaps a new library is a long-term way to 
address issues with RegExp, but if the problems can be fixed in RegExp 
itself, obviously that would be for the best (assuming the changes don't 
cause significant compatibility problems).

--Steven Levithan
 



More information about the es-discuss mailing list