extension modules

Brendan Eich brendan at mozilla.com
Tue Jun 23 11:11:47 PDT 2009


On Jun 23, 2009, at 10:03 AM, kevin curtis wrote:

> The requirement of security and speed don't always coincide! The  
> subset/dialect idea is interesting.

It's two-edged.

Adding standard subsets leads to case-analysis explosion, a recipe for  
bugs and reduction of interoperability.

How subsets might evolve in future editions is another axis for  
explosion of cases. Are subsets partially ordered in the same way  
across future editions? Or should there be a total order? Can strict  
mode get stricter over time?

    ES5 ---------------> ES6 ...
     ^                    ^
     |                    |
    ES5 strict <---?---> ES6 strict ...

The arrowhead points to the superset. At some point we might have ESn  
remove ancient cruft so the horizontal arrows might stop pointing  
rightward.

These are good questions and there may be compelling and simple  
answers, but only for very few standard subsets. If you can't draw the  
lattice, it's too complicated.

Ideally, IMHO, the only standard subset will be strict mode.


> let x:int = 0 // ES6 type annotation to indicate this will be turned  
> into a c int at some point
> ... etc

We do not want int "for performance" if it auto-widens to double.  
Adobe has experience here, and int as an annotation on local variables  
(e.g. loop controls) is often a de-optimizer, yet users over-use it  
"for speed".

If as you propose ("C int", capital C meaning the C language, I take  
it) we enable 32-bit machine int under a pragma, we'll have wraparound  
bugs on the web. (People will copy and paste the pragma to excess.)

Because of the web-as-it-is, implementors have had to optimize JS as  
it is used.

But this has demonstrated, to me at least, that the important language  
optimizations can be done well under the hood, without hinting. IMHO  
this is a good use of human capital, compared to the alternative of  
unleashing pragmas and machine types on the web developer masses,  
where the pragmas and types add complexity and often bite back.

The issue with "self-hosting" or "systems programming" goes beyond a  
machine int type, however. One would want packed structs that can be  
stack allocated and embedded in arrays (no references to heap- 
allocated objects). One would surely want flat vectors, not prototype- 
delegating hashmap-happy Arrays.

You may be right that this sauce for the goose would be wanted by the  
web-dev gander soon enough, but not all at once and prematurely  
standardized.

Such a variant of JS could be made memory safe, but it is overkill at  
this stage for the Web. The best way to proceed is for Mozilla, e.g.,  
to prototype such a language. We're thinking seriously about it right  
now.

It's not an Ecma TC39 agenda item until years from now, when such  
prototypes have been deployed and used at scale, but in domain- 
specific silos.

We'll do our development, if we do it, of such a systems-programming  
dialect of JS, in the open and in open source, so everyone on this  
list who is interested can watch and participate. But it would be a  
distraction to overuse this list for discussions about such a dialect.


> Also, performant c++ code seems to use templates rather than  
> traditional OO with virtual methods. Nitro/v8/tm seem to doing a  
> form of dynamic templating

Goes back to the Self work in the 90s, of course. No type annotations.


> when at runtime they try to figure out the types that are being  
> passed as parameters to functions and generate machine code. (Or in  
> hot loops in tm's case).

TM infers static types on trace, this is a difference from the method- 
based speculative approaches. That is, we inline aggressively, so type  
annotations on parameters to otherwise generic methods could frustrate  
it.


> Maybe the engines could be given a helping hand via the ES subset in  
> perf modules - and type annotations.

This is a malinvestment for the masses, with too much blowback  
potential.


> But too many subsets could add confusion.

I agree -- sorry, I should have read ahead, but you seemed not to see  
this earlier.


> Type annotations are in ES6 (i think).

Not yet, and not as anything that resembles static machine types.


> Could there be a subset that meets both security and performance  
> issues.

Why are you mixing the two still? As you note they conflict sometimes.

SES is an experiment, not ready for standardization. I don't think a  
"PES" can be supported by Ecma TC39 at this point, even if that were  
the place. But again, it's not: implementors need to experiment, in  
the open but ideally in more than one lab, with more than one approach.


> Or even perf as a subset of secure. e.g: use secure, perf. Would a  
> performance subset need to be unsafe/unmanaged.

On the web, definitely safe/managed (memory-safe at the least!).

In systems programming domains where C++ is used, possibly not. It  
depends on the domain.

For Mozilla's systems-ish domains, we would want memory safety,  
control flow integrity, and other properties to be enforced. But we  
would be willing to take advantage of static/dynamic analysis duality,  
and spend more time on static analysis to achieve memory safety and  
other properties, with the benefit of lower runtime overhead.

/be


More information about the es-discuss mailing list