Re: Re: Look-behind proposal in trouble

The experimental implementation [0] in V8 landed a few days ago and is included in the latest Canary build (49.0.2568.0 and later). You can test it after enabling it with the command line flag --js-flags="--harmony-regexp-lookbehind". Apparently the port to SpiderMonkey is already underway [1].

Re: Backward running version look-behinds (Re: Look-behind proposal in trouble)

> Le 19 nov. 2015 à 20:17, Nozomu Katō a écrit : > > On Thu, 19 Nov 2015 09:04:41 +0100, Yang Guo wrote: >> This implementation supports variable length lookbehind similar to .NET's >> semantics. It does so by emitting code to read backwards inside the >> lookbehind. The

Backward running version look-behinds (Re: Look-behind proposal in trouble)

On Thu, 19 Nov 2015 09:04:41 +0100, Yang Guo wrote: > This implementation supports variable length lookbehind similar to .NET's > semantics. It does so by emitting code to read backwards inside the > lookbehind. The size of the change without platform ports and tests is > about 600 lines. When

Re: Re: Backward running version look-behinds (Re: Look-behind proposal in trouble)

FWIW this is precisely how it works in .NET as well (reverse order of capture and back reference). While it might be surprising, it makes sense with the backward read direction in mind. I'm not fond of the idea of throwing syntax error if the back reference is to the right of the capture inside a

Re: Look-behind proposal in trouble

And here's a similar playground for .Net, not by me: http://www.regexplanet.com/advanced/dotnet/index.html On Tue, Nov 10, 2015 at 11:08 AM, Erik Corry wrote: > I made a playground where you can try out regexps with lookbehind. > >

Re: Look-behind proposal in trouble

I made a playground where you can try out regexps with lookbehind. https://dartpad.dartlang.org/8feea83c01ab767acdf1 On Tue, Oct 13, 2015 at 9:24 PM, Nozomu Katoo wrote: > Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200: > > Yes, that makes sense. > > > > This

Re: Look-behind proposal in trouble

Yes, that makes sense. This could be fixed by removing {n} loops from positive lookbehinds. Or by doing the .NET-style back-references immediately. On Mon, Oct 12, 2015 at 10:01 PM, Waldemar Horwat wrote: > On 10/10/2015 03:48, Erik Corry wrote: > >> >> >> On Sat, Oct 10,

Re: Look-behind proposal in trouble

On 10/13/2015 02:18, Erik Corry wrote: Yes, that makes sense. This could be fixed by removing {n} loops from positive lookbehinds. Or by doing the .NET-style back-references immediately. I think it would be cleanest to do the full reverse-order matching (what I think you're calling

Re: Look-behind proposal in trouble

Erik Corry wrote on Tue, 13 Oct 2015 at 11:18:48 +0200: > Yes, that makes sense. > > This could be fixed by removing {n} loops from positive lookbehinds. Or by > doing the .NET-style back-references immediately. Personally, I am reluctant to remove any feature from the current proposal

Re: Look-behind proposal in trouble

Just for the lulz I ran the tests I could find from perl5 (which I think is very similar to the proposal here) and the captures were identical when using .Net-style reverse capturing. It's not a huge number of tests, though. On Sat, Oct 10, 2015 at 12:48 PM, Erik Corry

Re: Look-behind proposal in trouble

On 10/10/2015 03:48, Erik Corry wrote: On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat > wrote: It's not a superset. Captures would match differently. Can you elaborate? How would they be different? If you have a capture inside a

Re: Look-behind proposal in trouble

On Sat, Oct 10, 2015 at 12:47 AM, Waldemar Horwat wrote: > > It's not a superset. Captures would match differently. Can you elaborate? How would they be different? -- Erik Corry ___ es-discuss mailing list

Re: Look-behind proposal in trouble

astian Zartner [mailto:sebastianzart...@gmail.com] > *Sent:* Monday, October 5, 2015 10:56 PM > *To:* Nozomu Katō <noz...@akenotsuki.com> > *Cc:* Brian Terlson <brian.terl...@microsoft.com>; es-discuss Mozilla < > es-discuss@mozilla.org>; Gorkem Yakin <goya...@micro

Re: Look-behind proposal in trouble

Waldemar Horwat wrote on Fri, 9 Oct 2015, at 15:47:08 -0700: > On 10/09/2015 15:07, Nozomu Katō wrote: >> As Jason Orendorff wrote before, the lookbehind supported by .NET is a >> strict superset of what I have proposed. So, if you or someone else >> submits another lookbehind proposal based on

Re: Look-behind proposal in trouble

Sorry, I wrote: > Since there was a comment about Perl5 style vs .NET style when I first > posted my proposal to es-discuss, I meant "when I first posted my proposal to es-discuss, too, ". ___ es-discuss mailing list es-discuss@mozilla.org

Re: Look-behind proposal in trouble

Since there was a comment about Perl5 style vs .NET style when I first posted my proposal to es-discuss, I just wanted to explain about the background of my proposal. I proposed Perl5 compatible lookbehinds because I thought it was relatively simple to implement. Moreover, I am not confident that

Re: Look-behind proposal in trouble

> Le 9 oct. 2015 à 15:00, Nozomu Katō a écrit : > > Erik Corry wrote on Fri, 9 Oct 2015, at 10:52:09 +0200: >> I made an implementation of .NET-style variable length lookbehinds. It's >> not in a JS engine, but it's in a very simple (and very slow) >> ES5-compatible

Re: Look-behind proposal in trouble

Erik Corry wrote on Fri, 9 Oct 2015, at 10:52:09 +0200: > I made an implementation of .NET-style variable length lookbehinds. It's > not in a JS engine, but it's in a very simple (and very slow) > ES5-compatible regexp engine that is used in the tiny Dart implementation > named Fletch. > > No

Re: Look-behind proposal in trouble

I'm not convinced that the current proposal is easier to implement than the real thing. Take a look at the patch, it's trivial. The lack of variable length lookbehind is a big annoyance in most languages. Search for the term and you'll find lots of frustrated perl users. On the other hand I

Re: Look-behind proposal in trouble

Your proposal for look-behind relies on being able to count the match length of the look-behind in order to step back that far. This presupposes that atoms like . and character classes have a fixed length. However, with the /u flag, the . and some character classes can be either 1 or two code

Re: Look-behind proposal in trouble

Oops forgot the /u on the regexp in the example. On Wed, Oct 7, 2015 at 10:06 AM, Erik Corry wrote: > Your proposal for look-behind relies on being able to count the match > length of the look-behind in order to step back that far. This presupposes > that atoms like . and

Re: Look-behind proposal in trouble

What Claude mentioned is already part of the specification: "Input is a List consisting of all of the characters" and "Each character is either a code unit or a code point, depending upon the kind of pattern involved" (21.2.2.1). But I added the Note section to the page of my proposal for

Re: Look-behind proposal in trouble

This should not be a problem: With the /u flag, you work with code points, not code units. In particular, the `.` matches always a sequence (of code points with /u, or code units otherwise) of length 1. —Claude > Le 7 oct. 2015 à 10:08, Erik Corry a écrit : > > Oops

Re: Look-behind proposal in trouble

> Le 7 oct. 2015 à 11:16, Erik Corry a écrit : > > The proposal needs to be clarified to explain that you are stepping back a > number of code points, not units. This implies that you are inspecting the > input string as you step backwards. Also it should be explained

Re: Look-behind proposal in trouble

The proposal needs to be clarified to explain that you are stepping back a number of code points, not units. This implies that you are inspecting the input string as you step backwards. Also it should be explained what to do if there are unpaired surrogates in the input string and inside the

RE: Look-behind proposal in trouble

erlson <brian.terl...@microsoft.com>; es-discuss Mozilla <es-discuss@mozilla.org>; Gorkem Yakin <goya...@microsoft.com> Subject: Re: Look-behind proposal in trouble Hi together, Brian, where can people get the information about the reasons of such decisions (besides asking)

Re: Look-behind proposal in trouble

Hi together, Brian, where can people get the information about the reasons of such decisions (besides asking) and more generally about the processes behind the ES development? I was following Nozomu's proposal[1] closely, though to me it looked like the progress on this just died out.

RE: Look-behind proposal in trouble

ubject: Look-behind proposal in trouble Apparently my proposal for adding the look-behind assertions to RegExp has been in trouble. I would like to ask anyone for help. The following story is what I know about the proposal after my previous post: I created a pull request for the proposal i

Re: Look-behind proposal in trouble

Hello Brian, I thank you very much indeed for your email and bringing really good news! I thought that my proposal might not be able to move forward anymore. I am also thankful that you searched for a new champion and Gorkem undertakes this proposal! Regards, Nozomu Brian Terlson wrote on

Look-behind proposal in trouble

Apparently my proposal for adding the look-behind assertions to RegExp has been in trouble. I would like to ask anyone for help. The following story is what I know about the proposal after my previous post: I created a pull request for the proposal in July and sent an email to Brendan Eich