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 t
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
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/>
Doesn't really say anything I haven't said somewhere in this thread
already, though.
--
David "liore
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 m
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
On 14/09/2007, Brendan Eich <[EMAIL PROTECTED]> wrote:
> "Almost all" excludes IE JScript, right?
Well, it doesn't agree with me on what is the right approach, but it
does agree with me that the ES3 approach is wrong.
> Those implementations are
> JavaScriptCore, based on PCRE, and what else?
Th
On Sep 14, 2007, at 12:42 PM, liorean wrote:
> On 14/09/2007, liorean <[EMAIL PROTECTED]> wrote:
>> Maybe you don't. But almost all regex implementations that implement
>> capturing submatches that are specifically implementing the ES3
>> algorithm agree with me.
>
> s/that are specifically/that a
On 14/09/2007, liorean <[EMAIL PROTECTED]> wrote:
> Maybe you don't. But almost all regex implementations that implement
> capturing submatches that are specifically implementing the ES3
> algorithm agree with me.
s/that are specifically/that are not specifically/
--
David "liorean" Andersson
___
> On 9/13/07, liorean <[EMAIL PROTECTED]> wrote:
> > That the spec doesn't match expectations and that there are behaviours
> > that do make sense to replace it with, coupled with the fact there
> > seems to be no obvious compatibility problem with changing it
> > (otherwise JScript and JavaScriptC
On 9/14/07, Brendan Eich <[EMAIL PROTECTED]> wrote:
> I am not looking to make trouble here, believe me, but I want to
> point out two things that could help David's case:
>
> 1. JS regexps were modeled by me (to lwall's horror ;-) on Perl
> regexen. Here's what perl (5.8.8) does:
>
> $ perl
> "aaa
I am not looking to make trouble here, believe me, but I want to
point out two things that could help David's case:
1. JS regexps were modeled by me (to lwall's horror ;-) on Perl
regexen. Here's what perl (5.8.8) does:
$ perl
"aaab" =~ /(a\1)+|b/;
print "$& ($1)\n";
b ()
It's no surprise Ja
On 9/13/07, liorean <[EMAIL PROTECTED]> wrote:
> On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> > The current behavior
> > is well-defined; it's not a hardship for anyone; the incompatibilities
> > among the engines are probably not a big deal (thus the incompatible
> > engines can be ch
On 13/09/2007, Lars T Hansen <[EMAIL PROTECTED]> wrote:
> My answer to you is obviously that you should implement the ES3
> behavior (as should JScript and JavaScriptCore).
Of course I'll implement the ES3 behaviour if ES4 makes no change to
it, I just think it would be better to change the behavi
It is true that named submatches are just aliases for numbered
submatches. My argument was only that programmers are vastly less
likely to nest a named backreference inside the capturing submatch of
that name than they are when the backreference is a number, because it
will be much more obvious wh
Sorry for delaying my response on this. Wanted to get some public
opinions on it:
http://web-graphics.com/2007/09/05/a-quick-js-quizz-for-anybody-who-think-they-know-regex/>
Sadly I only got responses from two developers, but they both seem to
agree with me (and I was careful to not state my opini
On 9/2/07, liorean <[EMAIL PROTECTED]> wrote:
>
> var
> re=/(a\1)+|b/,
> a=[],
> key,
> aab=re.exec('aab')
> aaab=re.exec('aaab');
> for(key in aab)
> a.push('aab["'+key+'"]: '+aab[key]);
> for(key in aaab)
> a.push('aaab["'+key+
Hello,
I've been playing around with implementing ES3/ES4 regex, (more based
on observation of what the browser hosted engines seem to do than by
the spec, since I'm trying to build a non-backtracking engine) and
noted this case where the browsers don't agree:
var
re=/(a\1)+|b/,
17 matches
Mail list logo
