Closed hujiajie closed 10 years ago
If you mean you have no way to infer anything from JavaScript about local because it is a free variable then you are absolutely correct. Such information would violate the security guaranteed by the closure. For the prototype this meant that such situations were not handled. Fortunately if you are implementing ParallelJavaScript in the context of a system like Firefox (and Ion monkey) then the system’s native compilers have access to information inside a closure, such as about the var local, and the native compilers can compile the code correctly.
From: hujiajie [mailto:notifications@github.com] Sent: Wednesday, November 27, 2013 1:34 AM To: hujiajie/pa-blink Subject: [pa-blink] [rework] typeinference.js: add variables defined in an outer scope to the bindings and the flow graph (#7)
There is a critical problem. Let's consider the following example:
function f() {
var arr = [1, 2, 3, 4];
// declare a local variable
var local = 1;
// use the local variable in the elemental function
arr.mapPar(function (val) { return val + local; });
}
While parsing the elemental function, we have no way to infer the type and value of the variable 'local'. Thus, only global variables will be allowed in the elemental function. I think this is a fatal defect.
— Reply to this email directly or view it on GitHubhttps://github.com/hujiajie/pa-blink/issues/7.
We have agreed not to handle local variables defined in an outer scope (and actually there's no way to handle them on the JS side). The support for global variables is still missing now, and I'll open other issues to track this.
There is a critical problem. Let's consider the following example:
While parsing the elemental function, we have no way to infer the type and value of the variable 'local'. Thus, only global variables will be allowed in the elemental function. I think this is a fatal defect.