On March 04, 2010 11:07 AM, Brendan Eich wrote:
Right. I was explicit about hypothesizing an ecosystem solution,
independent of the standard and predicated on fast JS engines. This is
not meant to preempt your great work making RegExp incrementally better.
We (by which I mean "you" with edit
On March 04, 2010 11:40 AM, Andy Chu wrote:
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
I worked on something like this:
http:
> 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
I worked on something like this:
http://code.google.com/p/json-pattern/ . It is
On Mar 3, 2010, at 11:44 PM, Steve L. wrote:
(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 "Reg
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 kee
> 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 featur
> If we agree on /y, is the remainder of your proposal to simply add a pos
> (and possibly endPos) argument to the exec and test methods? I'd be all for
> that if the lastIndex property was also deprecated. I've argued for the same
> thing at http://blog.stevenlevithan.com/archives/fixing-javascrip
On February 23, 2010 8:50 AM, Andy Chu wrote:
So now that Erik Corry pointed out that /y as a compilation option
matches the implementation, as mentioned I don't mind leaving it out
of the method parameters. The "pos" is the one that still should be a
method argument.
[...]
/y works for me. I
On Feb 17, 2010, at 12:45 AM, Brendan Eich wrote:
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.
Prior to and after this discussion (I wavered a bit in the middle), I'm
inclined to agree wi
> 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.
I'm glad we're not following Perl to Perl 5 regexps.
Not clear on the "pos per pair" statement. All th
(belated followup)
> I think a lot of people (myself included) use a similar mental model,
> although it doesn't quite match the implementation details. But even
> according to this model, avoiding /y wouldn't keep ES regex flags pure as
> mere pattern attributes since ES already crossed that brid
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 standard
2010/2/15 Steve L. :
> 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 lastI
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 stri
On Feb 13, 2010, at 12:14 AM, Steve L. wrote:
\G and ^ become more dissimilar conceptually when \G is not used as
the leading element. With or without /m, ^ can be thought of as a
one-character lookbehind that doesn't need to know the current
search position index. With something like /\d|\
2010/2/12 Erik Corry :
Agree that \G breaks some logical barrier. I like to have a mental
model of the implementation internals, and \G breaks that a bit.
\G is more flexible and it is rather similar to ^ conceptually.
The mental model happens to be out of sync with how regexps are
implement
2010/2/12 Andy Chu :
Agree that \G breaks some logical barrier. I like to have a mental
model of the implementation internals, and \G breaks that a bit.
If compatibility with Mozilla is not an issue, I actually prefer
Python's approach of .search() vs. .match(). It's not a part of the
regex;
> \G is more flexible and it is rather similar to ^ conceptually.
>
> The mental model happens to be out of sync with how regexps are
> implemented. The implicit .*? at the start of a regexp is actually
> the fastest way to implement since you are using the fast internal
> search mechanisms that t
elsif ($html =~ /\G<(\w+)[^>]+>/gc) {
>> ...
>> } elsif ($html =~ /\G&#?\w+;/gc) {
>> ...
>> }
>> }
>>
>> Sorry for the tangent, but I thought it might be helpful to describe how \G
>> is used elsewhere.
>>
>&g
> One thing I didn't bring up is that Python actually has an "endpos"
> argument. You do regex.search(s, 10, 20), and it will stop at
> position 20. I couldn't think of a real use case for this. But
> anyone can think of one, that might be a consideration and sway things
> in favor of separate m
gt;/gc) {
> ...
> } elsif ($html =~ /\G&#?\w+;/gc) {
> ...
> }
> }
>
> Sorry for the tangent, but I thought it might be helpful to describe how \G
> is used elsewhere.
>
> Steven Levithan
> http://blog.stevenlevithan.com
>
> --
---
From: "Steve L."
Sent: Wednesday, February 10, 2010 10:46 AM
To: "Andy Chu" ; "es-discuss"
Subject: Re: Proposal for exact matching and matching at a position in
RegExp
http://andychu.net/ecmascript/RegExp-Enhancements-2.html
Basically the proposal is to
http://andychu.net/ecmascript/RegExp-Enhancements-2.html
Basically the proposal is to add parameters which can override the
internal state of the RegExp.
Does anyone have any comments on this?
Can I put it in a place where it will be considered for the next
ECMAScript? The overall idea seem
On Feb 9, 2010, at 9:50 AM, Andy Chu wrote:
However, expanding the language by adding extra parameters to
existing
functions is annoying because it means you can't test for the
presence
of absence of the feature with a simple if:
if (RegExp.funkyNewFunction) {
...
}
That's true, I would w
On Tue, Feb 9, 2010 at 7:34 AM, Kam Kasravi wrote:
> Hi Andy
> I had mentioned to Brendan at the last TC39 that you had ported narcissus
> and had observed the cost of match.
> There is a new global regexp parameter called 'y' which prevents the copy
> from occurring.
> I've taken a look at narcis
> However, expanding the language by adding extra parameters to existing
> functions is annoying because it means you can't test for the presence
> of absence of the feature with a simple if:
>
> if (RegExp.funkyNewFunction) {
> ...
> }
That's true, I would want to be able to test for the feature
rg/show_bug.cgi?id=542621
thx
kam
From: Andy Chu
To: es-discuss
Sent: Mon, February 8, 2010 11:46:06 PM
Subject: Re: Proposal for exact matching and matching at a position in RegExp
On Wed, Jan 27, 2010 at 10:03 PM, Andy Chu wrote:
> (The original mess
2010/2/9 Andy Chu :
> On Wed, Jan 27, 2010 at 10:03 PM, Andy Chu wrote:
>> (The original message was held up in spam moderation for awhile)
>>
>> Here is an addendum, after it was pointed out to me that this issue
>> has come up before:
>>
>> http://andychu.net/ecmascript/RegExp-Enhancements-2.htm
On Wed, Jan 27, 2010 at 10:03 PM, Andy Chu wrote:
> (The original message was held up in spam moderation for awhile)
>
> Here is an addendum, after it was pointed out to me that this issue
> has come up before:
>
> http://andychu.net/ecmascript/RegExp-Enhancements-2.html
>
> Basically the proposal
(The original message was held up in spam moderation for awhile)
Here is an addendum, after it was pointed out to me that this issue
has come up before:
http://andychu.net/ecmascript/RegExp-Enhancements-2.html
Basically the proposal is to add parameters which can override the
internal state of t
Here is a very simple proposal. If I can get access to the wiki I
could copy it in, but for now it's here:
http://andychu.net/ecmascript/RegExp-Enhancements.html
Comments appreciated.
thanks,
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
htt
31 matches
Mail list logo
