import.meta and TC39 process as a whole

[T.J. Crowder]

On Sat, Aug 5, 2017 at 11:05 AM, Naveen Chawla
<naveen.chwl at gmail.com> wrote:
>
> Does existing code use modules??? My understanding is that
> modules are a recent concept.

Yes, people have been using ES2015-style modules for a couple of years now
(obviously, modules in general much longer than that), via transpilers and
bundlers, and recently with some initial native implementations (Chrome v60
has it behind a flag, I think v61 will have it by default; I believe
there's a Safari tech preview). But I mostly meant code in general (and/or
which is bundled up in a module at some point), not module-specific code.

> And the `module` keyword would only apply in actual modules

I imagine that's possible. In general, something that's an identifier in
some code but a keyword in other code doesn't sound like a good idea to me.
But there's something *like* a precedent: Until ES5, you couldn't use a
keyword as a literal property name (e.g., in a property accessor --
`element.class` and `element.for` were famously syntax errors, leading to
the DOM using `className` and `htmlFor` instead); as of ES5, you can,
because the context is sufficiently clear that the accessor and object
initializer productions could use *IdentifierName* rather than
*Identifier*. Your concept goes further, making the *same production* parse
as a keyword in *ModuleBody* code but an identifier in *ScriptBody* code.

These issues don't exist with `import`, which has been a "future" reserved
word for 20 years. So while `module` may be *slightly* more semantically
obvious, I think you'll struggle to get people on-board with the complexity
of adding a context-sensitive keyword.

-- T.J. Crowder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/7718def2/attachment-0001.html>