On Fri, Feb 10, 2012 at 11:51 AM, François REMY <fremycompany_...@yahoo.fr> wrote: > The idea would be that each time the parser hit an issue, it replaces the > current block by a { throw new InvalidProgramException(); } but continue to > parse. It may also write a warning into the console. This is roughly how CSS > is working. The idea is not of me, but from Ian Hickson if I remember > correctly.
I can appreciate the try-catch block (vs functions or modules). But you can't just replace a block of unknown code because you won't know where it ends. So you'll need some kind of delimiter, regardless. - peter > > -----Message d'origine----- From: Peter van der Zee > Sent: Friday, February 10, 2012 11:27 AM > To: es-discuss > Subject: Fallback > > > There's currently no way of introducing anything new into the language > that breaks syntax. I think that point has been made very clearly with > harmony/es6. Can we introduce a way to make these transitions easier > in the future? > > CSS has a very simple way of gracefully ignore rules it doesn't know. > In CSS you can specify rules and features and whatever the engine > doesn't understand, it will ignore gracefully and continue. While this > obviously won't work out of the box for js. But I think we can work > around it. In CSS this is scoped to individual rules. In js there's no > notion of rules (and "lines" won't work either) but you could talk > about functions or modules (or blocks?) in the same way. I think > modules are a bit too big scoped for this but I'd like to discuss the > generic idea first. We can always bikeshed over the syntax later. I'll > work with function-like syntax for now. > > Say a browser wanted to support a new keyword. Right now, that's > impossible to even experiment with unless you write an entire engine > in js and have a duplicate source code for fallback. You simply can't > do something like > > x ||= y; > > without breaking the code permanently and without exception. We can > only add stuff that fits perfectly within the existing grammar. > There's also no way for a vendor to implement this as an experiment > because it will still break in older versions of the browser or other > vendors. So what if we could do something like this? > > function foo(x,y){ > "if es7"; > return x ||= y; > "/es7"; > } // the "/directive" serves as a delimiter because otherwise you'd > never know where to stop parsing when you don't support it > if (!foo) { > var foo = function(){ > x = x || y; > return x; > } > }; > > So now you have a way to experiment with the new extension and a > simple way of extending the language permanently, while still having > backwards compat (at least up to the point that we introduce this > system), graceful failures and a proper way of figuring out a > fallback. If a vendor did not support the feature asked for it could > declare `foo` as null or something allowing easy support detection. > > The declared function should work within the existing js language of > course and should be callable from within js with the regular > mechanics. This includes stuff like call, apply, and bind. Whatever > the function itself does with the arguments or the context is up to > the implementation. Whatever it returns should again be a proper js > value. This allows you to easily fallback to an "es5" function because > the fingerprint would be the same (and besides, I have no idea how > else this could work otherwise anyways). > > This also could allow introduction of vendor prefixes. However, for > now I'd like to focus on the general principle though and leave the > prefix discussion for later. > > Some syntax possibilities: > > function foo(){ "es7"; x ||= y; } > function foo(){ "es7"; x ||= y; "/es7"; } > condFunction foo(){ "es7"; x ||= y; } > condFunction "es7" foo(){ x ||= y; } > condFunction "es7" foo(){ x ||= y; } "es7"; > > Personally, I'd prefer a function-scoped capability over a > module-scoped capability because I think I'd like to apply this to > smaller snippets rather than an entire module. Or maybe both. > > Open things for me: > - How to efficiently specify the (scope of) things you want to opt-in to? > - How to limit the problem with interoperability this would > undoubtedly cause (even with prefixes). > - Proper keyword/syntax for this, would still like to keep this js-ish > - Is nesting desirable? Reasonably feasible? Especially wrt the delimiter > - This system would also allow for non-js extensions (like > coffeescript or even ruby/etc), is that a problem? > > If we think such a system is viable and we can find a simple way of > introducing it to the language, we should do it sooner than later. The > sooner it's in, the less "stuck" we will be in the future. > > - peter > _______________________________________________ > 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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss