Forwards-compatible syntax proposal

[Ian Hickson]

On Mon, 12 May 2008, Lars Hansen wrote:
> >
> > One of the problems with ES4 relative to ES3 is that the new syntax 
> > means that a script using ES4 features doesn't work in ES3 compilers.
> 
> To be precise, what you're saying is that there are ES4 source fragments 
> that can't be parsed by ES3 compilers.
> 
> I have various reactions to this statement, but among the top contenders 
> are :
> 
>   * rejecting syntactically invalid scripts is a feature,
>     not a bug

That's what the XML proponents argued, but I think we can firmly say that 
that is a failed experiment, at least on the Web. :-) CSS and HTML already 
have the feature that they are resilient to new syntax, I think the 
forward compatibility this offers is far more valuable than the 
"draconian" error handling in JS today.


>   * a quiet fallback is going to make web developers' lives even
>     worse, having to content not just with incompatible
>     implementations of a known language but implementations that
>     may censor content in scripts

Certainly I agree that developer tools should report these invalid blocks 
proactively; I'm not suggesting that the failure mode should be any more 
silent than today's failure mode. I'm only suggesting that the failure 
mode be reduced in scope from the program-level (<script> block) to the 
lexical level ({} block).


>     (As syntax evolves across multiple language versions, different
>     parts of the language are censored by this mechanism, so
>     an ES5 program running on an ES3 implementation and an ES4
>     implementation would have two different behaviors.)

Right, that's the idea. :-)


>   * this looks like compatibility handling that applies to a 
>     particular environment, and like handling <!-- syntax it
>     seems like something browser vendors might try to agree
>     on outside the forum of ECMAScript

I'm not sure I follow what you mean here.


> Another reaction is that there are ES4 source fragments that
> /can/ be parsed by ES3 compilers, but whose meaning will silently
> be something completely different in the two versions of the
> language.  Here are some:
> 
>   // a generator expression in ES4, a loop calling a function
>   // in ES3
> 
>   function f(x) {
>       for ( i=0 ; i < 10 ; i++ )
>           yield (f(), i)
>   }
> 
>   // (artificial) three statements in ES3, two in ES4
> 
>   x = this function 
>   f(x)
>   {  x++ }

I think this is very dangerous, and unwise, in the context of the Web. I 
strongly believe that if we want to have success in expanding the Web 
platform, backwards-compatibility is critical. But that's another issue.


> Finally, I'm worried that accepting your proposal will prevent a 
> language processor from reporting syntax errors.  This seems like it has 
> important usability problems.

I agree that we should be careful to define this in a way that doesn't 
preculde lanugage processors from actively reporting all syntax errors, 
even if the resulting code still compiles in some sense.


> All programs using exceptions for control flow are candidates:
> 
>    function trampolineLoop(f) {
>        for (;;)
>            try {
>                return f();
>            }
>            catch (x) {
>                f = x
>            }
>    }
> 
>    function f1() { throw function () { return f2(...a) } }  // splat is ES4 syntax
> 
>    trampolineLoop(f1)
> 
> This program loops forever if the ES4 body is replaced by code that 
> throws a syntax error.

How would this be different from the same program in an out of memory 
situation where calling f1 results in an OOM exception?

(As an aside -- I've no idea what the above program is supposed to do. 
Maybe the new syntax in this example needs some work to make it more 
intuitive, I'm not sure.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'