Why is "export default var a = 1;" invalid syntax?

Glen Huang curvedmark at gmail.com
Mon Dec 15 23:50:38 PST 2014


With the help of your explanation, the spec becomes much easier to read. Thanks.

Would you consider adding this:

Syntax
	export default var VariableDeclaration;

ExportEntries
Let entries be a new empty List.
Let name be the BoundNames of VariableDeclaration.
Repeat for each name in names,
Append to entries the Record {[[ModuleRequest]]: null, [[ImportName]]: null, [[LocalName]]:name, [[ExportName]]: “default" }.
Return entries.
Vice versa for LexicalDeclaration.

> On Dec 16, 2014, at 3:20 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> 
> 
> On Dec 15, 2014, at 10:06 PM, Brendan Eich wrote:
> 
>> Ah, thanks -- I remember someone pointing this out, now that you mention it.
>> 
>> My misunderstanding in the last two posts dings my ES6 quiz score! Who will get a perfect score in a fresh (uncoached) quiz setting? Is this telling us something? Anyway, I agree that `export default function a() {}` making an `a` binding is better, it resolves the confusing aspect in my misunderstood version of ES6 that Glen cited in his 7pm post.
>> 
>> One more question below:
>> 
>> Allen Wirfs-Brock wrote:
>>>> This seems clear. As Dave said, he originally proposed an '=' in between 'default' and the *expression* to evaluate on the right. That design remembrance should make clear that the default export is a function expression (not function declaration) with 'a' the name only in the scope of that function (either for recursion or as a downward funarg).
>>>> 
>>>> The 'default' binding won't be mutated via the final 'a = 2' statement, so the default-exported value is still the result of evaluating the function a(){} expression.
>>> 
>>> Not quite how it actually ended up.  See https://bugs.ecmascript.org/show_bug.cgi?id=2302 <https://bugs.ecmascript.org/show_bug.cgi?id=2302> for background.
>>> 
>>> export default function ...
>>> export default function  * ...
>>> export default class ...
>>> 
>>> all act as declaration that create a module local binding (for the name in the declaration part)  that is initialized in the normal manner (hoisted for function/function*,  statement order initialization for class).  In addition that binding is exported using the reserved export name 'default'. Just like, an export of the same declaration without 'default', except such declaration use the same name for both the export name and the local binding name.
>> 
>> So assigning `a = 2` won't affect the value of the default export, but will rebind `a`, given preceding `export default function a() {}` -- right?
> 
> It does both.  'a' is rebound to 2 and since the export name 'default' associates to 'a', any subsequent references in other modules tht are linked to the default export of this module will also see 2 because 'default' is really just the export name for 'a'.
> 
>> 
>>> For export default, if the declaration is anonymous (this required some minor syntax tweaking) , a local binding is still created (and initialized in the manner manner) but the local binding isn't locally referencable because it doesn't have a name that can be referenced via an IdentifierReference.
>> 
>> Hmm, how's that work? Throwaway symbol name?
> Well ultimately it's all linkages that at the implementation level hopefully resolve external (ie imported) references into direct references to exported variable binding.
> 
> At the spec. level, I just define a non-identifer name ("*default*") to the binding created by a anonymous 'export default'.  There can only be one per modules. It turns out all the declaration instantiation, binding lookup,  and module linking mechanism in the spec. work fine with such a name, so there is actually very few special cases in the spec. for such anonymous default exports. See https://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-exports-static-semantics-exportentries <https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports-static-semantics-exportentries> for how exports associate an export name with either a local binding name or an import name from some other module.
> 
>> 
>> I ask because Glen also wondered about the Module Record being reified in one of his posts. That's spec-internal, though (again, correction welcome).
> 
> Right, Module Record is just internal spec. mechanism used to define the module semantics.  It currently isn't reified.
> 
> Allen
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141216/c1a36b29/attachment-0001.html>


More information about the es-discuss mailing list