(Targeted replies below, too much to digest in one pass. :-P)
On May 8, 2009, at 8:49 PM, Kris Kowal wrote:
"(function (require, exports) {" + text + "/**/\n}"
Nit-picking a bit on names: require : provide :: import : export -- so mixing require and export mixes metaphors. Never stopped me ;-).
This doesn't enforce the "program" construction, and some of the JavaScript language semantics suffer for it. For example, function statements aren't defined and do not necessarily get bound to the module scope in some implementations.
What makes functions eval'ed hermetically by the module function occur in a statement context? They should be nested function declarations, not (sub-)statements. Or I'm missing something.
To address the latter problem, the engine would need to provide a program evaluator that begins with two scopes, one with globals, the other for module locals, wherein top-level declarations (and potentially free assignment, if that can't simply be culled from modules) are bound to the locals instead of the globals.
This is a language change. ES1-5 put free variables created by assignment in the object at the bottom of the scope chain.
I believe this addresses issues with Mark's idea:eval.hermetic() does an indirect eval of the program in the current global context, but, as in <http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope>, without the global object at the bottom of the scope chain.
Mark is citing a proposal that *removes* the global object from the scope chain; that proposal does not fiddle with where declared and free vars go.
Implementations would need to decouple the top of the scope chain and the global object.
Implementations can do this easily, but the issue is language-level: is the global object at the bottom of the scope chain? So far, it is.
With the addition of a "eval.parse(text):AST", we could recover some performance lost with this method, by sharing AST's among sandboxes.
I've considered exposing the AST encoder as eval.parse. It's a cute trick to use eval as a namespace, tempting in order to minimize compatibility hits in adding to the global object. But it feels a little "off" here.
Also, the AST codec I'm writing produces and consumes strings of JsonML. It's up to the user to invoke the JSON codec (or not), taking the hit of building a big array/object graph only as needed. This should not be a mandatory consequence of parsing from source to an AST form that can be consumed by the engine. You shouldn't have to go from
source string -> object graph -> JsonML stringin the language itself, since the middle step can chew up a fair amount of memory compared to an incremental (top-level-declaration-or- statement at a time or better), native parser that feeds its internal AST into a native stringifier.
/be _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
