Proposal for exact matching and matching at a position in RegExp
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:
> 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
>> 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
>> proposals from that page you think are most likely to gain any traction,
>> 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
> (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
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).
More information about the es-discuss