Spawn proposal strawman

Brendan Eich brendan at
Mon May 11 09:26:56 PDT 2009

(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
>> <>,
>> 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 string

in 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.


More information about the es-discuss mailing list