[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

On Oct 30, 2007, at 4:04 PM, Mark Miller wrote:

> AFAIK, the only subset relationships here with unqualified  
> compatibility are JSON < ES3 and JSON < proposed ES4. All the  
> others have hazards that programmers need to understand in order to  
> make use of the subset relationship. In this sense, the situation  
> is analogous to C being approximately a subset of C++: When writing  
> a correct C program, if you know what hazards to avoid, it isn't  
> much harder to write it (without ifdefs) so that it's also a  
> correct C++ program.

Someone just submitted a patch to old C code in Mozilla, to a header  
file. All void f(); prototypes became void f(void); for C++ to be  
happy. This avoided warnings, so it was not strictly required, at  
least not by the compilers we use.

ES4 does not require, or even warn in favor of, any such syntactic  
changes to existing ES3 code.

> Although many may prefer C to C++, no one would propose C as a  
> successor to C++. Nevertheless, it's valuable to both communities  
> to maintain this almost-compatible-subset property between the  
> languages. Likewise, it would make no sense to propose Caja as a  
> successor to ES3.

Sure, but my thought was that a Caja-like language supported by  
browsers might be successful enough that it should be considered for  
standardization. For that to happen (I think), the objections to  
profiled standards would have to be overcome.

> So, depending on what you mean, I might argue with your phrase  
> "incompatible subset". We are seeking to create, as close as we  
> possibly can, a compatible subset. If you see a way in which we  
> could be more compatible while still meeting our other goals,  
> please let us know. Thanks.

I thought I saw something, but I just reread the Caja paper and don't  
see it. Sorry about the false alarm -- it's a proper subset (and well  
done too). Question about it: do you allow the alternative way people  
create prototypes for constructor functions? Instead of

function F(a...){...}
F.prototype.mname = /*method or function*/;
F.prototype.pname = /*expr with no F*/;
...
F.sname = /*function or expr with no F*/;

the following is popular:

function F(a...){...}
F.prototype = {
     mname: function (a,b,c) {...},
     pname: /*expr with no F*/,
     ...
};
F.sname = /*function or expr with no F*/;

> Also, could you explain the phrase "profiled standards"? Thanks.

Standards with a menu of profiles, usually progressively subsetted,  
for implementations to choose from. One example: MPEG-4 has profiles  
(and levels, to support different qualities of encoding that can be  
decoded several ways, IIUC):

http://en.wikipedia.org/wiki/MPEG-4

ECMAScript has a compact profile:

http://www.ecma-international.org/publications/standards/Ecma-327.htm

As the overview for ES4 notes, the Web has not been kind to the  
compact profile. Mobile browser vendors found that, outside of walled- 
garden content, they had to implement the full ES3 spec.

It could be that profiles make sense "next time", more than they  
have. It might be a historical accident that ES3 became so  
widespread. Still, people on TG1 who have expressed an opinion about  
profiled standards also worry about the complexity, the size of the  
testing problem in ensuring that the profiles are in a subset  
relation, the specs don't contradict one another, and implementations  
work together. I remember PHIGS and PEX (which makes me think of X  
Windows, and now I'm sad).

>
> Anyway, it's early days for Caja and other such systems. If TG1  
> continues to function, it should definitely harvest good ideas from  
> it, and stand on shoulders, not toes.
>
> Thank you. I will read the ES4 proposal carefully and let you know  
> what shoulder and toe issues I find.

That's great, thanks.

> I would like to hear more about this. A safe eval primitive that  
> provides good isolation could actually be a very powerful lever for  
> expressive security.

A sketch in ES3:

String.prototype.evaluate = function (scope) {
     /* eval this in scope and only scope -- no other scope chain  
contents! */
};

"a + b * c".evaluate({a: 2, b: 5, c: 8}) => 42

For ultimate compatibility and integrity, it might be better to  
provide this only as a fixed static method (can't be replaced or  
overridden due to finality) of string:

string.evaluate(someStringLikeThing, theScoleScopeObject);

/be