> Le 26/09/2013 15:36, Bradley Meck a écrit :
>> The only really think of that would be of benefit is parallel execution.
> MongoDB MapReduce exploits parallelism as much as one can ever hope and
> just a string generated from
> var f = '' + function(){...}
> seems to work just fine.Firstly, this is kinda ugly (and not entirely secure, someone could override Function.prototype.toString). Secondly, the point here is not to enable parallelism but to enable safe execution of JS code anywhere without access to any specific context. The fact the code runs in a "clean" environment make it safe and determinist, and the fact it cannot possibly leak anything to the outside world make it possible for very powerful optimizations. For instance, you can create any object on the stack and bypass GC. > This has already been happening in the real world for several years with > the language as it is. What would be the benefit of changing the language? Let's imagine, for a second, that we have that "animationTimingFunction" and that we want to implement our own function (ie: not a cubic bezier or any of the default model) then the problem is that the browser cannot call a function at any time because that function may access the DOM which is not ready at that time, and there's no way to prevent that. If we have a special kind of function that is guaranteed not have access to anything more that what was given to it, we can start envisioning using those functions deeper in the browser stack. For example, we could easily use this kind of function to generate custom layout code, why not? The second case would be a customizable javascript algorithm that does not want to reveal any information about himself. If I receive an abritrary function, he cannot be sure the function won't be leaking information to the outside world by using a global variable, even if he actively "re-eval" the string representation of the function. The last thing is that a "safe" function opens many doors for optimization, like I said before. Here's another example: because you *know* Math.sin is the default sin function, you can bypass the Math object, the sin function, and directly call the native "sin" function. If you're running in an uncontrolled environment, you don't know. Maybe the user replaced Math with something else, or sin. You need to have guards and safety checks before doing the optimization. This also opens doors to very straightforward inlining. You can inline the function and not recheck guards after the function has been called, because you know it doesn't have side effects. If you want your code to run inside the critical parts of a browser, any optimization is good to take! With "safe" functions, you can generate code that is exactly as fast as C++ while not restricting the user to the ASM.js limits. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
