Does the RegExp /y modifier require /g?
(I emailed this to the list last night, but it doesn't seem to have gone
through. Sorry if this becomes a dupe.)
-
As far as I understand from ECMA-262 3rd Edition, the regexp.lastIndex
property is meaningless if a regexp does not use the /g modifier. Quoting
from E262v3 ยง15.10.6.2 (RegExp.prototype.exec):
> 4. Let i be the value of ToInteger(lastIndex).
> 5. If the global property is false, let i = 0.
So, e.g., the following returns true, although it would return false if /g
were used:
var re = /x/;
re.lastIndex = 2;
re.test("xyz"); // true
Given the above rule, my questions are:
1. Does ES4's /y (sticky) modifier have any meaning if the /g (global)
modifier is not also set?
2. What about with String.prototype.split and String.prototype.search, which
ignore the values of regexp.global and regexp.lastIndex?
The extend_regexps proposal on the wiki does not specifically mention these
points, and the sticky modifier does not appear to be implemented in the ES4
reference implementation (the sticky property gets set with /y, but it
doesn't appear to work).
I'm working on code which brings some of the ES4 regex features (including
/y) to current browsers, but I'm not sure which way to go on these points.
--
View this message in context:
http://www.nabble.com/Does-the-RegExp--y-modifier-require--g--tp14488851p14488851.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Add call and apply methods to RegExp.prototype
Yes, its easy to pull off oneself, so I don't care much other way. Still, it seems pretty weird to me to be able to do ``regex(str)`` but not ``regex.call(context, str)``. This is accentuated when typeof returns "function" for regexes (though it seems ES4 will change this to "object"). Yuh-Ruey Chen wrote: > > Sounds like a good idea to me. On the other hand, this can already > easily be done in ES3. > > Steven L. wrote: >> ES4 proposals include making regexes callable as a function on a >> single string argument, which serves as a shorthand for calling the >> regex's exec method. To further extend this idea, what about also >> including call and apply methods on RegExp.prototype ... > > -- View this message in context: http://www.nabble.com/Add-call-and-apply-methods-to-RegExp.prototype-tp14429329p14457280.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
StevenLevithan wrote: > > And I've posted a follow-up > http://blog.stevenlevithan.com/archives/es3-regexes-broken here (which in > truth is more of a long rant). > At the risk of spamming the mailing list, I'll note that I've just toned down a lot of the previous, undue negativity towards the draft ES4 regex spec in that post. I'm not really a hateful ingrate. :) -- View this message in context: http://www.nabble.com/Regex%3A-How-should-backreferences-contained-in-the-capturing-match-they-reference-to-work--tf4367560.html#a13984745 Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
liorean wrote: > > Tried to sum up the issue a little more coherently and well > articulated in a blog post: > http://web-graphics.com/2007/11/26/ecmascript-3-regular-expressions-a-specification-that-doesnt-make-sense/> > And I've posted a follow-up http://blog.stevenlevithan.com/archives/es3-regexes-broken here (which in truth is more of a long rant). BTW, here's another variation on the use of Perl-style group participation handling that I posted on a regex forum yesterday: http://regexadvice.com/forums/permalink/25764/36926/ShowThread.aspx#36926 Reg Expression for matching [multiple required attributes] (that regex also uses an atomic group, but that's not imperative in this case and can be emulated even in ES3 by using capturing groups in lookahead, if necessary). The Perl-style handling is intuitive and ripe for creative exploitation. The ES3-style handling is essentially useless. But I'll stop beating this horse now... -- View this message in context: http://www.nabble.com/Regex%3A-How-should-backreferences-contained-in-the-capturing-match-they-reference-to-work--tf4367560.html#a13964984 Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
StevenLevithan wrote: > > > liorean wrote: >> >>> I think I can sum up the change I think is appropriate by these things: >>> - undefined should be a failure to match instead of a match to the empty >>> string >>> - captures should only be set to undefined in two cases - when the >>> regex matching is started, and if inside a negative lookahead >> > > I am in complete agreement with liorean. The ES3 handling on these points > is non-intuitive, non-compatible with other regex libraries, *far* less > useful than the alternative (I could give countless examples of where the > Perl-style handling has real-world practicality), and creates future > compatibility issues if ECMAScript were to implement certain features from > Perl or other Perl-derivative flavors such as capturing-group-based > conditionals. > To support my last comment with a couple of the "countless examples", I can point to my blog: - If backreferences to non-participating capturing groups resulted in failure rather than a match of the empty string, it would be possible to mimic conditionals as shown at http://blog.stevenlevithan.com/archives/mimic-conditionals http://blog.stevenlevithan.com/archives/mimic-conditionals . That page presents some generalized patterns, but simpler cases can often be taken advantage of. - If captures were only set to undefined when the regex matching starts and after a negative lookahead which contains captures, it would be possible to do things like shown at http://blog.stevenlevithan.com/archives/multi-attr-capture http://blog.stevenlevithan.com/archives/multi-attr-capture . Those are particular things I've posted about in the past, but I run into these spec bugs ;-) on a regular basis. I have never run into a case where I wished for the ES3 handling of these issues. -- View this message in context: http://www.nabble.com/Regex%3A-How-should-backreferences-contained-in-the-capturing-match-they-reference-to-work--tf4367560.html#a13946533 Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Regex: How should backreferences contained in the capturing match they reference to work?
liorean wrote: > >> I think I can sum up the change I think is appropriate by these things: >> - undefined should be a failure to match instead of a match to the empty >> string >> - captures should only be set to undefined in two cases - when the >> regex matching is started, and if inside a negative lookahead > I am in complete agreement with liorean. The ES3 handling on these points is non-intuitive, non-compatible with other regex libraries, *far* less useful than the alternative (I could give countless examples of where the Perl-style handling has real-world practicality), and creates future compatibility issues if ECMAScript were to implement certain features from Perl or other Perl-derivative flavors such as capturing-group-based conditionals. Lars T Hansen wrote: > >> I hope I'm not being overly flip when I say that it is the spec that >> circumscribes the set of expectations you are allowed to have. And >> the spec is entirely clear here, ie what it says is not in question, >> even if it's not always easy to find out what it says. A somewhat >> determined developer who needs to rely on the behavior can discover >> what behavior is expected (though he obviously can't trust the >> implementations to get it right). > I consider ES3's handling of capturing group participation and so forth (summed up by liorean) to be bugs in the spec (perhaps I'm being overly flip, but these are my biggest gripes with ES3 regexes). The fact that I consider them bugs which might be fixed in future versions means that I cannot rely on the behavior even though I understand what the spec prescribes. -- View this message in context: http://www.nabble.com/Regex%3A-How-should-backreferences-contained-in-the-capturing-match-they-reference-to-work--tf4367560.html#a13946131 Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Suggest adopting .NET/Perl regexp named capture syntax
Thanks for the feedback and for opening the ticket.
Lars T Hansen-2 wrote:
>
>> One other question... can the results from named capture be used in a
>> replacement closure function? I.e., will you be able to do something like
>> str.replace(/(?P)/,function(match){return match.name;}); ?
>
> The captured substrings with names are available as properties on the
> match result object, so that should work, yes.
>
> --lars
>
But the match result object is not available within a replacement closure
function, hence the question. At least in ES3, arguments[0] is a string
primitive containing the entire match (i.e. backreference zero). It could be
changed to a String object and have the named backreferences attached to it
as properties (which is how I handle the issue in my
http://stevenlevithan.com/regex/xregexp/ XRegExp library), but this is
fundamentally a different thing, and might have some obscure potential for
compatibility issues.
--
View this message in context:
http://www.nabble.com/Suggest-adopting-.NET-Perl-regexp-named-capture-syntax-tf4682705.html#a13390450
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Suggest adopting .NET/Perl regexp named capture syntax
ECMAScript 4 regular expression extension proposals indicate that the Python
syntax will be used for named capture. Python uses (?P...) for named
capture, (?P=name) for a backreference within the regex, and \g for a
backreference within a replacement string. Personally, I feel this a
mistake.
Although Python was the first to implement named capture, other libraries
seem to be standardizing around .NET's alternative syntax, which uses
(?...) or (?'name'...) for capture, \k or \k'name' for a
backreference within the regex, and ${name} for a backreference within a
replacement string. Perl 5.10 has adopted .NET's syntax (although
backrefereces within a replacement string use $+{name}) since "most people
consider it to be nicer". Recent versions of PCRE have followed Perl's lead
by supporting .NET's syntax for named capture as the preferred style.
Here are the problems I see with the Python syntax:
(?P...)
- What does the "P" stand for? "Python"? The character is unnecessary and
unhelpful.
(?P=name)
- Backreferences should not use parentheses since they are a single token
and not a grouping.
\g
- Is this a single token in ES4, or a string which in a string literal will
have to be written as "\\g"? If it is the former, how will you be able
to generate a replacement string using e.g. a textarea with user input, and
if it's the latter, it seems less elegant than ${name} , which follows the
'$ denotes a backreference' convention.
One other question... can the results from named capture be used in a
replacement closure function? I.e., will you be able to do something like
str.replace(/(?P)/,function(match){return match.name;}); ?
--
View this message in context:
http://www.nabble.com/Suggest-adopting-.NET-Perl-regexp-named-capture-syntax-tf4682705.html#a13380696
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
