On 2010-07-15, at 8:21 AM, Maxime Chevalier-Boisvert wrote:
You are putting in ast-passes.js (an early pass of the compiler)
some knowledge of the runtime system (the way globals are accessed).
It makes sense to me that globals shouldn't be captured as closure variables, no matter how we implement them. Seems like something we know will hold true, no matter how we implement the system.
In a previous meeting I explained that a JavaScript system may need to support more than one top-level environment. For example, browsers have one top-level environment per window. It is conceivable that a closure created in one top-level environment will be "sent" or shared with code running in a different top-level environment. This might be useful for one browser window to interact with another window. I don't want to argue whether this is a good thing or not. I don't know at this point. However, we should structure the compiler so that this is an option if we want to try it out. Given that this is a runtime system issue (how top-level environments are implemented), the decision to exclude global variables should be made in the middle or back-end of the compiler.
And as I said, even if we ignore the modularity issue, we don't want to waste space in two tables (free_vars and clos_vars) that duplicates the information.
Having the global variables in the free variables is also useful for generating linking information. The free variables of the "Program" node are the global variables that the module imports/exports.
Marc