Spawn proposal strawman

David-Sarah Hopwood david-sarah at
Mon May 11 18:14:25 PDT 2009

Kris Kowal wrote:
> On Mon, May 11, 2009 at 9:26 AM, Brendan Eich <brendan at> wrote:
>> 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 ;-).
> 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() {};
> 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.

Neither "import" nor "export" are ES3 or ES5 keywords. However, both
are context-dependent keywords in Mozilla JavaScript:


I don't know whether any future 'import' or 'export' syntax could be
made not to collide with the Mozilla extensions.

> 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 is perfectly standard (and implemented correctly cross-browser).
The body of the outer function is a sequence of SourceElements, which
allows a FunctionDeclaration. 'foo' is bound only within the outer
function's scope.

David-Sarah Hopwood ⚥

More information about the es-discuss mailing list