The requirement of security and speed don't always coincide! The subset/dialect idea is interesting.
The tracemonkey, v8 and nitro engines have the ability to compile to machine code. How about: 'performance modules' which would be written in and parsed as a subset of ES which is *extremely sympathetic to the machine code generating infrastructure* of the ecmascript engines and thus generates efficient machine code. Without being to closely tied to (specific) implementations. For example: module myfastmod; use performance; // pragma that indicates this is perf module let x:int = 0 // ES6 type annotation to indicate this will be turned into a c int at some point ... etc Code in a performance module that does not interact with the ES VM via module public api's should be able to be compiled particularly efficiently. 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 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). Maybe the engines could be given a helping hand via the ES subset in perf modules - and type annotations. But too many subsets could add confusion. Type annotations are in ES6 (i think). Could there be a subset that meets both security and performance issues. Or even perf as a subset of secure. e.g: use secure, perf. Would a performance subset need to be unsafe/unmanaged. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
