Languages *evolve*. It means that at some point something will be introduced 
that may break existing user code.

I understand that with JS the problem is compounded a billion-fold (JS is used 
quite literally everywhere).

However: Looking at the evolution of JS we can see that new entities and new 
assumptions (potentially breaking user code) are continuously added to and 
removed from JS (as they should).

So, in my opinion, the argument for not adding new global entities such as 
System, or Module, or Loader (or heck, even all three of them) being “these are 
not keywords, we can’t introduce them” is really really weak.

On Sat, 05 Aug 2017 at 12:45 "T.J. Crowder"

> wrote:

a, pre, code, a:link, body { word-wrap: break-word !important; }

On Sat, Aug 5, 2017 at 11:05 AM, Naveen Chawla

> 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
es-discuss mailing list

Reply via email to