import.meta and TC39 process as a whole

[Logan Smyth]

> The thing is, I clearly provide arguments in favour of my opinion.
>
> We now have:
> - keywords that are just keywords, really (typeof, case, break, etc.)
> ...

Totally fair. I understand that's where your coming from.

> How can adding “properties” to semantically fundamentally different
things elegant? Or increasing the number of extremely context-dependent
things? Or overriding existing keywords with new and exceedingly confusing
behaviours?

This is an argument for literally never changing the language. New things
always seem confusing at first, then you learn and move on.

> Riiiight. Because import.meta is not a magically-populated
not-quite-global variable. Oh. Wait. That’s *exactly* what it is.

`Introspect` is a variable with well-defined existing behavior as a
variable. `import` is not a variable, it has no meaning when used as a
value until the spec assigns it a behavior. That is the point I'm trying to
get across. Is it less than ideal? Yeah, having `module` as a keyword would
be perfect, but we have to work within the bounds of the language that we
have.

> Even though it’s worse. import is a not-really-a-function-not-
really-an-object-not-really-a-static-not-really-a-dynamic-keyword which is
clearly far worse than a properly defined API.

What is a properly defined API for this case? Access to `.meta` needs to be
able to know what module you are inside of. It needs some kind of context
that ties it to the file that is asking for metadata. Within the existing
behavior of the language, we can't just make a new global object like
`Symbol` or `Reflect` because it has no way to know what file is asking for
metadata.

The options are either:

* Add new syntax to expose the per-module-specific information, like
`import.meta`, which cannot conflict with any existing code.
* Co-opt existing property-access behavior to make it behave differently
from how it would in other contexts, like `Introspect.context`. It would
either have to introduce an entirely new keyword, which as I mentioned is a
breaking change, or it would have to fundamentally override the behavior of
accessing a property on an object to allow the object to know what module
the property was accessed from.

Since new keywords are out the window, I guess it could be said that the
argument here are two sides, one arguing for more syntax to keep the
execution model simple (import.meta) vs keeping the syntax simple at the
expense of making the runtime behavior of the code more complex by changing
how property access works.

I fall on the side of syntax because changing the behavior of property
access to expose the current file seems massively more complex and seems
much more likely to me to confuse people.


On Sat, Aug 5, 2017 at 2:29 PM, Jordan Harband <ljharb at gmail.com> wrote:

> > There’s no code anywhere which doesn’t have an object called Symbol
> invoked with `new Symbol()`?
> Any such code would either have a local `Symbol`, would have defined a
> global `Symbol` that shadowed any pre-defined one (including the new global
> in ES6), or would have thrown a ReferenceError or TypeError. Adding
> `Symbol` won't break any of that code (because the code that threw was
> already broken).
>
> On Sat, Aug 5, 2017 at 2:20 PM, Dmitrii Dimandt <dmitrii at dmitriid.com>
> wrote:
>
>> > [Reflect] Not a breaking change because adding a new global isn't new
>> syntax, it's just a new variable that exists and essentially can't break
>> much.
>>
>> It either isn’t a breaking change, or can’t break much. It cannot be both.
>>
>> > Not a breaking change because this constructor did not exist before.
>>
>> Are you entirely sure? There’s no code anywhere which doesn’t have an
>> object called Symbol invoked with `new Symbol()`? The moment you add a
>> global anything, you break someone’s code somewhere.
>>
>> > I don't think I'd call super properties metaproperties for this reason.
>> `super` property access is its own class-related syntax that isn't related.
>> I do think it sets a perfectly reasonable guideline that makes it clear
>> most people have no problem accessing properties off of keywords.
>>
>> I fail to see where you see guidelines specced out in the specifications
>> of metaproperties or superproperties. “Most people” end up just stuck with
>> these because they are either unaware that these changes are coming or are
>> not active enough to voice their concerns.
>>
>> > The biggest issue for me in this whole thread is that it's all
>> extremely opinion-based. What one person calls complex another would call
>> elegant.
>>
>> The thing is, I clearly provide arguments in favour of my opinion. Let me
>> just summarise them for you.
>>
>> We now have:
>>
>> - keywords that are just keywords, really (typeof, case, break, etc.)
>> - keywords that are just keywords, but don’t even exist in a language.
>> They are reserved for future use in various contexts: always reserved, only
>> in strict mode, only in module code etc. (enum, public, private, await
>> etc.). May never be used and may possibly be removed, as some keywords have
>> been (int, byte, char etc.)
>> - literals that are basically keywords (null, true, false)
>> - non-keywords that are for all intents and purposes keywords (eval,
>> arguments)
>> - keywords that look like objects (because they have additional
>> properties) which are not objects (new with new.target)
>> - keywords that look like functions (because they are invoked like
>> functions and return values like functions) which are not functions (import
>> and import())
>> - keywords that look like objects *and* functions but are neither (import
>> and import() and import.meta)
>>
>> It gets even worse. Because “metaproperties” are not just attached to
>> keywords. They are attached to keywords which have *fundamentally different
>> semantics* in the language:
>> - `new` is an operator[2], it gets `new.target`
>> -  A function is a callable object [3], and it gets a `function.sent`
>> - import is … I don’t know what import is. It gets transformed into a
>> separate, made-just-for-import CallExpression and then it gets an
>> `import.meta` on top of that (as a hardcoded “metaproperty”).
>>
>> All of the above are basic facts about the language as it exists now. How
>> can adding “properties” to semantically fundamentally different things
>> elegant? Or increasing the number of extremely context-dependent things? Or
>> overriding existing keywords with new and exceedingly confusing behaviours?
>>
>> > > So there’s really *nothing* stopping you from designing a proper
>> System/Module/Loader/Introspect/Avocado or any subset thereof instead of
>> slapping “metaproperties” on everything in sight :)
>> >
>> > I don't think anyone has claimed that `import.meta` is meant as a
>> replacement for these. We still need a loader spec
>>
>> and a System spec and an Introspect spec, and ... That is why all these
>> random additions to vastly different things in the language look like
>> ad-hoc shortsighted solutions with no respect for the language or its
>> evolution. “We need a thing, we have nowhere to put this thing, let’s add
>> this thing to a keyword, because new.target (bad design) has opened a door
>> for us”.
>>
>> > I'd _much_ rather have a static syntactically-defined way to access
>> that information over a magically-populated not-quite-global variable like
>> `Introspect.context.sent`.
>>
>> Riiiight. Because import.meta is not a magically-populated
>> not-quite-global variable. Oh. Wait. That’s *exactly* what it is.
>>
>> Even though it’s worse. import is a not-really-a-function-not-real
>> ly-an-object-not-really-a-static-not-really-a-dynamic-keyword which is
>> clearly far worse than a properly defined API.
>>
>>
>> On Sat, 05 Aug 2017 at 22:37 Logan Smyth <Logan Smyth
>> <Logan+Smyth+%3Cloganfsmyth at gmail.com%3E>> wrote:
>>
>>> `await` could be added because there is no case in existing code where
>>> `await <expression>` would have been valid code, so it is
>>> backward-compatible. The same applies for all of the meta-property
>>> proposals. The same is not true for `Introspect.context.module`. It's not
>>> just a question of it a given construct could be made to behave the way you
>>> want, it's also a question of it it would be compatible with existing code.
>>>
>>> > Introduced in ECMASCRIPT 2015: Reflect is a built-in object that
>>> provides methods for interceptable JavaScript operations.
>>>
>>> Not a breaking change because adding a new global isn't new syntax, it's
>>> just a new variable that exists and essentially can't break much.
>>>
>>> > Introduced in ECMASCRIPT 2015: The Symbol() function returns a value
>>> of type symbol, has static properties that expose several members of
>>> built-in objects, has static methods that expose the global symbol
>>> registry, and resembles a built-in object class but is incomplete as a
>>> constructor because it does not support the syntax "new Symbol()”.
>>>
>>> Not a breaking change because this constructor did not exist before.
>>>
>>> > ECMAScript 5 introduced: yield, let
>>>
>>> Not a breaking change because those two can only occur in locations
>>> where they can't conflict with existing ES5 code. The extremely limited
>>> cases where `let` _could_ be in conflict are explicitly handled in the
>>> grammar to prevent breaking changes.
>>>
>>> > ECMASCRIPT 6 introduced: await as a reserved word in module code
>>>
>>> Same as above.
>>>
>>> > So, introducting new things into the language is not really such a big
>>> problem as it’s made out to be ;)
>>>
>>> No-one said introducing things was not possible, but we can't break
>>> existing code.
>>>
>>> > Don’t forget that `super` gets its own properties. Since there’s no
>>> specification of what “metaproperties” are, they are just called
>>> superproperties[7] in the grammar. Because reasons.
>>>
>>> I don't think I'd call super properties metaproperties for this reason.
>>> `super` property access is its own class-related syntax that isn't related. I
>>> do think it sets a perfectly reasonable guideline that makes it clear most
>>> people have no problem accessing properties off of keywords.
>>>
>>> > The problem with “metaproperties” is that they make the language more
>>> complex, chaotic and make it difficult to reason about the language.
>>>
>>> This seems to be the core of your argument, but I honestly don't quite
>>> see why it is more complex/chaotic. The biggest issue for me in this whole
>>> thread is that it's all extremely opinion-based. What one person calls
>>> complex another would call elegant.
>>>
>>> What specifically is difficult to reason about that wasn't already
>>> complex? Same for `function.arguments`. You're saying you think it's better
>>> to have an automatically-created `arguments` variable in every single
>>> function instead of having syntax to access it? `arguments` and `this` as
>>> two auto-initialized bindings are some of the most confusing parts of JS.
>>>
>>>
>>> > So there’s really *nothing* stopping you from designing a proper
>>> System/Module/Loader/Introspect/Avocado or any subset thereof instead
>>> of slapping “metaproperties” on everything in sight :)
>>>
>>> I don't think anyone has claimed that `import.meta` is meant as a
>>> replacement for these. We still need a loader spec, but having a syntactic
>>> way to access data about the current active module is absolutely a useful
>>> thing to have. It's no different than CommonJS's __dirname and __filename
>>> among others. The logic for implementing a loader is separate from the
>>> logic for defining the behavior of module execution itself.
>>>
>>> I'd _much_ rather have a static syntactically-defined way to access that
>>> information over a magically-populated not-quite-global variable like `Introspect.context.sent`.
>>> In a perfect world absolutely `module` could have been a keyword, but at
>>> this point making that change seems like an absolute no-go because it could
>>> easily break existing code.
>>>
>>> > Like look. function.sent?? Really? And it’s extremely highly
>>> context-specific: “function.sent can appear anywhere a YieldExpress would
>>> be legal. Referencing function.sent outside of a GeneratorBody is a Syntax
>>> Error.”
>>>
>>> It's the exact same context-specific behavior as `yield` and they are
>>> both tied to generator functions. How is that in any way unexpected?
>>>
>>>
>>> On Sat, Aug 5, 2017 at 12:43 PM, Dmitrii Dimandt <dmitrii at dmitriid.com>
>>> wrote:
>>>
>>>> I just realised that there is also the argument that “global object
>>>> cannot get current context” and other limitations applied to whether a
>>>> theoretical “System/Module/Loader/Introspect” would be a global
>>>> module, or object, or keyword, or any (potentially context-sensitive)
>>>> combination of these.
>>>>
>>>> However, this all basically depends on what you specify in the
>>>> standard, doesn’t it? :)
>>>>
>>>> - Dynamic import has a “forbidden extensions” section[1] and how it
>>>> should work when it’s invoked as a CallExpression [2]
>>>> - import.meta has a full section describing how the runtime should
>>>> behave when encountering this particular property[3]
>>>> - new global objects like Reflect, Proxy, Symbol have specifications on
>>>> what they are and hoe they should be treated [4]
>>>>
>>>> A theoretical global object/keyword/identifier/special form X could be
>>>> specified as <object/keyword/identifier/avocado>. X.someProperty: when
>>>> encountered, let context be Ctx, let A be B, and C be B, populate with
>>>> properties from here and there and everywhere.
>>>>
>>>> Or look at the AwaitExpression[5]. There are specific limits in place
>>>> to guard where and how it’s used and when it is to be evaluated as
>>>> AwaitExpression.
>>>>
>>>> So there’s really *nothing* stopping you from designing a proper
>>>> System/Module/Loader/Introspect/Avocado or any subset thereof instead
>>>> of slapping “metaproperties” on everything in sight :)
>>>>
>>>> Like look. function.sent?? Really? And it’s extremely highly
>>>> context-specific: “function.sent can appear anywhere a YieldExpress would
>>>> be legal. Referencing function.sent outside of a GeneratorBody is a Syntax
>>>> Error.” [6]
>>>>
>>>> Look. Here’s a proposal: `Introspect.context.sent can appear anywhere a
>>>> YieldExpress would be legal. Referencing Introspect.context.sent outside of
>>>> a GeneratorBody is a Syntax Error.` And then you can use
>>>> `Introspect.context.target` instead of `new.target`.
>>>> `Introspect.context.module` instead of `import.meta`. Clean. Reasonable.
>>>> Extensible. Future-proof.
>>>>
>>>> [1] https://tc39.github.io/proposal-dynamic-import/#sec-forb
>>>> idden-extensions
>>>> [2] https://tc39.github.io/proposal-dynamic-import/#sec-import-calls
>>>> [3] https://tc39.github.io/proposal-import-meta/#sec-source-
>>>> text-module-records
>>>> [4] https://tc39.github.io/ecma262/#sec-reflection, https://
>>>> tc39.github.io/ecma262/#sec-proxy-objects, https://tc39.gith
>>>> ub.io/ecma262/#sec-symbol-objects
>>>> [5] https://tc39.github.io/ecma262/#prod-AwaitExpression
>>>> [6] https://github.com/allenwb/ESideas/blob/master/Generator
>>>> %20metaproperty.md
>>>>
>>>>
>>>>
>>>> On Sat, 05 Aug 2017 at 20:40 dmitrii at dmitriid.com <dmitrii at dmitriid.com>
>>>> wrote:
>>>>
>>>>> The problem with “metaproperties” is that they make the language more
>>>>> complex, chaotic and make it difficult to reason about the language.
>>>>>
>>>>> See my previous post about the multitude of keyword and keyword-like
>>>>> types that the language has. It’s so bad that even “metaproperty” concept
>>>>> itself isn’t defined in the standard except as a hardcoded `new.target` [1]
>>>>>
>>>>> If you read, for example, through the import.meta draft, you see
>>>>> things ripe for inclusion in a proper API object.
>>>>>
>>>>> It gets even worse. Because “metaproperties” are not just attached to
>>>>> keywords. They are attached to keywords which have *fundamentally different
>>>>> semantics* in the language: `new` is an operator[2], it gets `new.target`.
>>>>> A function is a callable object [3], and it gets a `function.sent`. Import
>>>>> is … I don’t know what import is [4]. It gets transformed into a separate,
>>>>> made-just-for-import  CallExpression[5] and then it gets an `import.meta`
>>>>> on top of that [6] (as a hardcoded “metaproperty").
>>>>>
>>>>> Don’t forget that `super` gets its own properties. Since there’s no
>>>>> specification of what “metaproperties” are, they are just called
>>>>> superproperties[7] in the grammar. Because reasons.
>>>>>
>>>>> All this is chaos from the perspective of developer experience. And
>>>>> truly looks like random ad-hoc solutions to immediate problems with no
>>>>> long-term goals. Imagine how much better *and* future-proof it would be if
>>>>> all this was in the form of a unified centralised API? There is a reason
>>>>> people laugh at PHP for its API and language design.
>>>>>
>>>>> [1] https://www.ecma-international.org/ecma-262/#sec-meta-properties
>>>>> [2] https://www.ecma-international.org/ecma-262/7.0/#sec-new-operator
>>>>> [3] https://www.ecma-international.org/ecma-262/7.0/#sec-ter
>>>>> ms-and-definitions-function
>>>>> [4] https://www.ecma-international.org/ecma-262/7.0/#sec-imports
>>>>> [5] https://tc39.github.io/proposal-dynamic-import/#sec-left
>>>>> -hand-side-expressions
>>>>> [6] https://tc39.github.io/proposal-import-meta/#sec-left-ha
>>>>> nd-side-expressions
>>>>> [7] https://www.ecma-international.org/ecma-262/7.0/#sec-lef
>>>>> t-hand-side-expressions
>>>>>
>>>>>
>>>>> On Sat, 05 Aug 2017 at 18:59 Matthew Robb <Matthew Robb
>>>>> <Matthew+Robb+%3Cmatthewwrobb at gmail.com%3E>> wrote:
>>>>>
>>>>>> I really can't find a good resource on direct vs indirect evaluation
>>>>>> but my understanding is it's one of the main considerations for using a
>>>>>> keyword over an identifier for contextual information. One example which is
>>>>>> already in the language would be 'eval' which you can read a little about
>>>>>> here: http://2ality.com/2014/01/eval.html
>>>>>>
>>>>>> Now you might be able to have an API that gets you the same result as
>>>>>> the context sensitive keywords but it would be less ergonomic among other
>>>>>> things: Reflect.getModuleMetaProperty(someModuleNs, 'propName') but
>>>>>> this becomes much more difficult to do FROM WITHIN THE MODULE ITSELF.
>>>>>> Anything that is, let's call it tangible, cannot receive implicit
>>>>>> contextual information it must have something passed to it that it would
>>>>>> use to look up said information.
>>>>>>
>>>>>> Sure there could be arguments made about introducing new environment
>>>>>> type records to the top level module scope of all modules but this is
>>>>>> potentially much more error prone and likely to lead to more and bigger
>>>>>> questions down the road. 'module' in particular is a really bad choice imo
>>>>>> as node/commonjs have already introduced a 'module' identifier into all of
>>>>>> their module scopes hence `module.exports = ...`. There may be solutions to
>>>>>> working around that in one form or another BUT the 'trend' in TC39 to use
>>>>>> keyword meta properties for context sensitive information is to avoid
>>>>>> solving ever edge case of conflict that would impact existing code and
>>>>>> users. It really is a fairly ripe space for powerful and ergonomic features
>>>>>> like `super` which feel like "magic". The same is true for import.meta but
>>>>>> it may be harder to identify right off as the uses haven't all been fully
>>>>>> introduced such as environment specific properties and potentialy other
>>>>>> loader hooks.
>>>>>>
>>>>>> NOW as I was writing this it came to mind that we DO have a new
>>>>>> syntactic form for private data coming in the form of private fields which
>>>>>> use a hash prefix. It would be interesting to explore using the same syntax
>>>>>> for module scoped private fields:
>>>>>>
>>>>>> ```js
>>>>>>
>>>>>> console.log(#dirname);
>>>>>> ```
>>>>>>
>>>>>>
>>>>>> - Matthew Robb
>>>>>>
>>>>>> On Sat, Aug 5, 2017 at 12:35 PM, Dmitrii Dimandt <
>>>>>> dmitrii at dmitriid.com> wrote:
>>>>>>
>>>>>>> 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" <">"T.J. Crowder" >
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt
>>>>>>>> <dmitrii at dmitriid.com> 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
>>>>>>> <dmitrii at dmitriid.com> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170805/0d7f523a/attachment-0001.html>