Getting SIMD.js into the TC39 repository
Hi Brian, ES-Discuss, The SIMD.js spec and polyfill still lives in John McCutchan's GitHub account. How can we transfer this to the TC39 account in accordance with ECMA's requirements? Thanks, Dan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Forbid implementations from extending the RegExp grammar.
On Jul 5, 2015, at 10:56 PM, Benjamin Gruenbaum wrote: > So, following work on RegExp.escape [1] I found out that implementations may > extend the regular expression grammar in JavaScript [2]. However, when asking > esdiscuss and Stack Overflow about it [2][3] it doesn't look like any > implementations currently do so (*). Actually, almost all ES implementation extend/modify the ES RegExp pattern grammar. Annex B.1.4 http://ecma-international.org/ecma-262/6.0/#sec-regular-expressions-patterns attempts to describe the interoperable RegExp extensions that are common among browsers. > > Can we please forbid implementations from extending the regular expression > syntax? It seems like this could cause compatibility issues between > implementations anyway. We have subclassable RegExp with hooks and symbols in > place and implementations that want to provide an extended RegExp can > subclass RegExp or propose an extension to the language itself. Can't do it, won't work. If followed, a general probation of syntactic extensions, whether for the entire language or just for RegExp patterns,would block all future language innovation. But, it practice it would just be ignored. We (think) we can get away with a few very targeted and well motivated extension prohibitions such a those listed in http://ecma-international.org/ecma-262/6.0/#sec-forbidden-extensions but broad a "no new syntax" prohibition would hold and isn't desirable. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: treated as a module if ...
On Jul 6, 2015, at 7:32 AM, John Barton wrote: > > > On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola wrote: > To be explicit: there is no way to look at a string of JavaScript text and > tell whether it should be treated as a module or a script. In many instances > the same string can be treated as both. > > The decision is made by the execution environment. > > I don't think Domenic meant that the standard explicitly states that the > execution environment may choose the parse method. Rather that the context > of loading the code determines the parsing method. > > I believe that the current status is that the standard describes the two > parsing methods but says nothing about when they will be applied. We do know > that
Re: Forbid implementations from extending the RegExp grammar.
Benji -- but you've just specifically mentioned that implementations are already using the flexibility provided by the spec to experiment with and implement ES6 features. Why are you going to foreclose that possibility for ES2016+? The perl community has managed to compatibly extend their regex engine to an almost absurd degree. There are plenty of ways to add features to your regexp that don't break "standard-compliant" regexps. I think that's the *spirit* of the existing language in the spec, and it should be honored. I'm fine with narrowing the scope, so we know that new flags and characters after `(?` are "reserved", for example, but I don't see why we have to ban future change outright. --scott On Mon, Jul 6, 2015 at 10:13 AM, Benjamin Gruenbaum wrote: > This isn't really about `RegExp.escape` as an issue. We can always extend > `RegExp.escape` when we make additions to the RegExp grammar as a standard > that would not be a problematic issue since we can keep both parts in sync > relatively easily. > > On the other hand currently implementations are allowed to diverge in their > regular expressions which means there is no guarantee that they'll behave > the same in some cases. This is really risky for standard behavior and if an > implementation decides to use the clause it could create a big pain point > for developers while keeping it compliant. > > Luckily, implementors are insightful people and implementations don't do > that because of precisely those usability implications for end developers. > > What I'm suggesting is that we forbid implementations from extending the > regular expressions grammar beyond the language specification and outside > the process. Basically, we take the ECMAScript regular expression object as > specified (minus allowing extensions) as our base line :) > > > Cheers, > Benji > > > On Mon, Jul 6, 2015 at 5:03 PM, C. Scott Ananian > wrote: >> >> I think it would be more worthwhile of we tried to draw a compatibility >> boundary. Taking perlre as a baseline, for example, are there additional >> characters we should escape in `RegExp.escape` so that implementations (and >> the language itself) could add more perlre features without breaking >> compatibility? The `(?...)` syntax (and flags) seems to be the de facto >> extension point, can we protect that more narrowly? >> --scott >> >> On Jul 6, 2015 1:56 AM, "Benjamin Gruenbaum" wrote: >>> >>> So, following work on RegExp.escape [1] I found out that implementations >>> may extend the regular expression grammar in JavaScript [2]. However, when >>> asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like any >>> implementations currently do so (*). >>> >>> Can we please forbid implementations from extending the regular >>> expression syntax? It seems like this could cause compatibility issues >>> between implementations anyway. We have subclassable RegExp with hooks and >>> symbols in place and implementations that want to provide an extended RegExp >>> can subclass RegExp or propose an extension to the language itself. >>> >>> >>> >>> >>> [1] https://github.com/benjamingr/RegExp.escape >>> [2] >>> https://esdiscuss.org/topic/why-are-implementations-allowed-to-extend-the-regular-expressions-syntax >>> [3] >>> http://stackoverflow.com/questions/30958288/what-ecmascript-implementations-extend-the-regexp-syntax >>> >>> (*) some did it to implement ES2015 features before ES2015. >>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: treated as a module if ...
On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola wrote: > To be explicit: there is no way to look at a string of JavaScript text and > tell whether it should be treated as a module or a script. In many > instances the same string can be treated as both. > The decision is made by the execution environment. > I don't think Domenic meant that the standard explicitly states that the execution environment may choose the parse method. Rather that the context of loading the code determines the parsing method. I believe that the current status is that the standard describes the two parsing methods but says nothing about when they will be applied. We do know that
Re: Forbid implementations from extending the RegExp grammar.
This isn't really about `RegExp.escape` as an issue. We can always extend `RegExp.escape` when we make additions to the RegExp grammar as a standard that would not be a problematic issue since we can keep both parts in sync relatively easily. On the other hand currently implementations are allowed to diverge in their regular expressions which means there is no guarantee that they'll behave the same in some cases. This is really risky for standard behavior and if an implementation decides to use the clause it could create a big pain point for developers while keeping it compliant. Luckily, implementors are insightful people and implementations don't do that because of precisely those usability implications for end developers. What I'm suggesting is that we forbid implementations from extending the regular expressions grammar *beyond the language specification and outside the process*. Basically, we take the ECMAScript regular expression object as specified (minus allowing extensions) as our base line :) Cheers, Benji On Mon, Jul 6, 2015 at 5:03 PM, C. Scott Ananian wrote: > I think it would be more worthwhile of we tried to draw a compatibility > boundary. Taking perlre as a baseline, for example, are there additional > characters we should escape in `RegExp.escape` so that implementations (and > the language itself) could add more perlre features without breaking > compatibility? The `(?...)` syntax (and flags) seems to be the de facto > extension point, can we protect that more narrowly? > --scott > On Jul 6, 2015 1:56 AM, "Benjamin Gruenbaum" wrote: > >> So, following work on RegExp.escape [1] I found out that implementations >> may extend the regular expression grammar in JavaScript [2]. However, when >> asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like >> any implementations currently do so (*). >> >> Can we please forbid implementations from extending the regular >> expression syntax? It seems like this could cause compatibility issues >> between implementations anyway. We have subclassable RegExp with hooks and >> symbols in place and implementations that want to provide an extended >> RegExp can subclass RegExp or propose an extension to the language itself. >> >> >> >> >> [1] https://github.com/benjamingr/RegExp.escape >> [2] >> https://esdiscuss.org/topic/why-are-implementations-allowed-to-extend-the-regular-expressions-syntax >> [3] >> http://stackoverflow.com/questions/30958288/what-ecmascript-implementations-extend-the-regexp-syntax >> >> (*) some did it to implement ES2015 features before ES2015. >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Forbid implementations from extending the RegExp grammar.
I think it would be more worthwhile of we tried to draw a compatibility boundary. Taking perlre as a baseline, for example, are there additional characters we should escape in `RegExp.escape` so that implementations (and the language itself) could add more perlre features without breaking compatibility? The `(?...)` syntax (and flags) seems to be the de facto extension point, can we protect that more narrowly? --scott On Jul 6, 2015 1:56 AM, "Benjamin Gruenbaum" wrote: > So, following work on RegExp.escape [1] I found out that implementations > may extend the regular expression grammar in JavaScript [2]. However, when > asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like > any implementations currently do so (*). > > Can we please forbid implementations from extending the regular expression > syntax? It seems like this could cause compatibility issues between > implementations anyway. We have subclassable RegExp with hooks and symbols > in place and implementations that want to provide an extended RegExp can > subclass RegExp or propose an extension to the language itself. > > > > > [1] https://github.com/benjamingr/RegExp.escape > [2] > https://esdiscuss.org/topic/why-are-implementations-allowed-to-extend-the-regular-expressions-syntax > [3] > http://stackoverflow.com/questions/30958288/what-ecmascript-implementations-extend-the-regexp-syntax > > (*) some did it to implement ES2015 features before ES2015. > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
