Spawn proposal strawman

[David-Sarah Hopwood]

Kris Kowal wrote:
> On Mon, May 11, 2009 at 9:26 AM, Brendan Eich <brendan at mozilla.com> 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:

<https://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/import>
<https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Statements/export>

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 ⚥