Modules: Curly Free

Andreas Rossberg rossberg at
Tue Apr 23 07:07:12 PDT 2013

On 23 April 2013 15:31, Sam Tobin-Hochstadt <samth at> wrote:
> 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.

Strictly speaking that would not be syntactic sugar either, because
the desugaring would be context-dependent in a manner that goes beyond
a simple pick-a-fresh-name regime (because it has to be
deterministically match on both ends of the export/import edge).

The only way to make it purely syntactic would be by picking an
ordinary variable name, once and for all. In other words, codify a
convention. ;)

But I agree that this all is a minor point, and playing some symbol
magic is close enough.


More information about the es-discuss mailing list