In a previous meeting I explained that a JavaScript system may need
to support more than one top-level environment.
In previous discussions, I suggested that we will want multiple global objects to separate our environment from executing programs. The way I plan on implementing this is to have a global object constant, which is different depending on what code is being compiled. For the Tachyon code, it will refer to our private global object, with JavaScript extensions included. For the code we compile, there can be separate global objects that will be specified at compile time. A function/source file compiled with a given global object will always refer to that same global object to access its globals.
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.
The way I have it conforms to the JS semantics, I find. The top-level environment is the global object. It's semantically an object, and it's where non-local variables are to be found. It makes little sense for individual global variables to be captured by a closure, because they are semantically different from local variables. You can delete global variables and access them using strings as names, for example, which you can't do with local/closure variables.
In terms of modularity, it makes perfect sense to keep all code related to variable resolution together, and as far as wasting space goes, at the moment, I have no need for free_vars. I'd rather still have clos_vars and esc_vars be computed in an AST pass at this time. Otherwise it forces me to include extra AST traversal code in the IR translation (particularly for esc_vars). If this somehow needs to be changed later, it's a pretty minor change to make.
Do you think you will have the updated variable resolution ready soon, and will you keep the computations of esc_vars and clos_vars in there?
- Maxime