Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you

On Sat, 05 Aug 2017 at 18:28 "T.J. Crowder"

> wrote:

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

On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt

> wrote:

> 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.

Is anyone making that argument? I certainly am not. Not only is it possible to 
add more global entities, as you point out, it's been done repeatedly: 
`Symbol`, `Reflect`, etc. They just can't be *keywords* without breaking 
things. They have to be identifiers. Which means they have bindings with 
values. Which means those values can be copied. Which has implications.

On Sat, Aug 5, 2017 at 5:08 PM, Dmitrii Dimandt

> wrote:


> That’s not what I was really aiming at :)


> The original concern was “to get ‘module’ : 1. It's a

> context-sensitive keyword, and code that's using it needs to 

> be updated when migrated to a module. “


> I was just pointing out that ‘import’ is already a context-

> sensitive keyword (as are a bunch of others, like super.

> Is super a keyword BTW?)

My point was that this would be the only case I know of where it would be a 
keyword in one context but an identifier in another in the *exact same 
production*. `super`, `import`, etc., are **always** keywords. You just can't 
use them except in certain contexts. So I shouldn't have said 
"context-sensitive keyword" so much as "keyword or identifier depending on 
context." (But then...I did, earlier; I figured the shorthand was okay after 
spelling it out longhand. :-) )

But again: Maybe that's feasible. Or maybe it's not a problem passing the value 
around, in which case a predefined `module` identifier only in module code 
isn't a problem anyway.

-- T.J. Crowder
es-discuss mailing list

Reply via email to