Spawn proposal strawman

[Brendan Eich]

On May 11, 2009, at 4:10 PM, Kris Kowal wrote:

> I agree about mixing metaphors.  The befuddlement of start : stop ::
> begin : end is one that bothers me a lot.  The notion is to desugar
> "import" and "export" to these two facets, importing and exporting.
> imports : exports would be proper, but doesn't read well in code.  The
> reason for using the term "exports" is to ease migration, since:
>
> exports.a = function a() {};
>
> Is easy to transform textually to:
>
> export a = function a() {};

Hmm, that cuts both ways. You can run a sed script or whatever, but if  
skimming or otherwise manually inspecting (humans are error-prone ;-)  
the difference is slight.


> So, I'm inclined to stick with "exports" instead of "provide".  The
> metaphor would be complete if we used "imports(id)" or "import(id)".
> Since "import" is a keyword, it would not be available for the
> desugarred syntax.  That leaves "imports".
>
> const {a} = imports("module");

Kinda works, yeah.


>> 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.
>
> Perhaps I'm behind on the times, but I'm under the impression that
> presently the behavior of this function "foo" declaration has no
> standard behavior:
>
> (function () {
>   function foo() {
>   }
> })();

No, that's fully specified by ES3.


> If foo gets bound in function block scope, there's no problem (which
> is the case in most browsers, I believe), but if it gets bound as a
> member of global, that would be a problem,

I know of no such bug. You might be thinking of a different IE bug,  
where named function expressions are evaluated to bind their names in  
the variable object.


> and if it gets bound like a
> free assignment, it would only be a problem if free assignment isn't
> localized to the module somehow.

No such bug in any implementation I've ever seen or heard of.


>>> 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.
>
> I've operated on the assumption that the global object was on the
> bottom of the scope chain.  There are some concerns about module texts
> for parsing and interpreting modules, some of which might be
> sufficiently addressed by moving global off the scope chain for module
> evaluation, but perhaps not necessarily.

Sounds like "use lexical scope" or (as the proposal happily allows)  
something subsuming it would do the trick, and provide other benefits.


> * free assignment.  I'm less concerned about the behavior of free
> assignment.  I'd prefer assignment to global to be explicit, but this
> ship may have sailed long ago.  It might be more appropriate for free
> assignment to create module locals or module exports, which could be
> accomplished by changing the bottom-of-the-scope-chain, or by changing
> the behavior of free assignment in the context of a hermetic eval.  In
> any case, this is not something I'm deeply concerned with.

ES5 strict mode makes free variable creation via assignment an error,  
so let's roll with that.


> * function statements.  These really must be module local.  I'm not
> in-the-know about whether this is a problem or not.

Not a problem.


> * return statement.  This should be a parse error in the top most
> scope of a module.  If hermetic eval wraps a module's text in a
> function declaration, the return statement would not be a parse error,
> which would be a problem.

The only way around this with existing tools is to eval the string  
body of the module-function, which will again make return a parse  
error. Double eval overhead.


> If heremetic eval returns a function that
> executes the module with a given require and exports object, then
> return would be a parse error in the bottom-scope.

I don't follow this sentence.


> * injection attack strings.  These are a weakness of using a hermetic
> eval that immediately evaluates a module factory function expression
> with the module text inside.

ASTs to the rescue? This just moves the injection attack surface,  
arguably shrinks it a good deal by breaking eval up into parse +  
execute (let's call it).

/be