Modules: Curly Free

Sam Tobin-Hochstadt samth at
Tue Apr 23 06:31:39 PDT 2013

On Tue, Apr 23, 2013 at 9:07 AM, Andreas Rossberg <rossberg at> wrote:
> On 23 April 2013 15:02, Sam Tobin-Hochstadt <samth at> wrote:
>> On Tue, Apr 23, 2013 at 8:55 AM, Andreas Rossberg <rossberg at> wrote:
>>> On 22 April 2013 22:10, David Herman <dherman at> wrote:
>>>> On Apr 22, 2013, at 6:48 AM, Andreas Rossberg <rossberg at> wrote:
>>>>> (And semantics, I presume, because
>>>>> Dave hasn't actually told us how the "anonymous" export would be
>>>>> distinguished internally.)
>>>> Yes I have! I've explained it before, at least at the March meeting and again in passing in this thread. The anonymous export would be available on the module instance object under a standard unique symbol.
>>> Just to be clear, AFAICT, this requires a semantic extension. A module
>>> body is, first and foremost, a lexical environment, and environments
>>> do not currently have a notion of symbol-named variables (nor should
>>> they, IMO).
>> No, this does not require a semantic extension. I think everyone
>> agrees that environments should not have symbol-named variables.
>> However, this is neither here nor there for module instance objects,
>> which are reflections of module exports as "plain" JS objects. There
>> is no semantic extension required for them to have symbol-named
>> properties.
> Then it is a semantic extension simply because default imports and
> exports cannot be rewritten to plain module syntax, i.e. are _not_
> syntactic sugar, right?

It can only be rewritten to regular exports provided that the
rewriting can choose an otherwise-unused name. We could define it as
syntactic sugar by simply saying that it uses the element of the set
`xx*` with the shortest length that is not otherwise an export of the
module.  However, I think we can all agree that such a solution would
be worse than using a well-known symbol.  I don't think there's a
meaningful difference in terms of whether it's a semantic extension.


More information about the es-discuss mailing list