T.J. Crowder (2018-03-29T15:37:09.000Z)
On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <sebastian at malton.name>
wrote:
>
> No because this is something that I am proposing as an extension
> to es import/export

The *ModuleSpecifier* string of `import` is entirely environment-specific,
not covered by the ECMAScript standard at all. From [Runtime Semantics:
HostResolveImportedModule ( referencingModule, specifier )][1]:

> HostResolveImportedModule is an **implementation-defined abstract
> operation** that provides the concrete Module Record subclass
> instance that corresponds to the ModuleSpecifier String,
> specifier, occurring within the context of the module represented
> by the Module Record referencingModule.

Instead of the ECMAScript spec definining it, it's left to environments to
define it appropriately for the environment, since different environments
have different design constraints and criteria. For instance, [this part of
the WHAT-WG HTML spec][2] covers using modules on the web (drawing on
various underlying initiatives such as [`import()`][3] and
[`import.meta`][4]). (In this initial version, unsurprisingly, module
specifiers are essentially URLs, with the requirement [for now] that
relative URLs must start with `/`, `./`, or `../` so that "bare" relative
URLs can be given meaning down-the-line.)

So if you want a special token for "root," that will be an
environment-specific request, not something for TC39.

Of course, TC39 could define some syntax (outside the *ModuleSpecifier*)
that says "work from the root" while still leaving it up to the environment
what "the root" is, but there's no particular reason to do that rather than
leaving it to environments to handle as part of the *ModuleSpecifier*.

-- T.J. Crowder

[1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
[2]:
https://html.spec.whatwg.org/#integration-with-the-javascript-module-system
[3]: https://tc39.github.io/proposal-dynamic-import/
[4]: https://tc39.github.io/proposal-import-meta/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180329/542c3947/attachment-0001.html>
tj at crowdersoftware.com (2018-03-29T15:47:35.191Z)
On Thu, Mar 29, 2018 at 2:49 PM, Sebastian Malton <sebastian at malton.name> wrote:
>
> No because this is something that I am proposing as an extension
> to es import/export

The *ModuleSpecifier* string of `import` is entirely environment-specific,
not covered by the ECMAScript standard at all. From [Runtime Semantics:
HostResolveImportedModule ( referencingModule, specifier )][1]:

> HostResolveImportedModule is an **implementation-defined abstract
> operation** that provides the concrete Module Record subclass
> instance that corresponds to the ModuleSpecifier String,
> specifier, occurring within the context of the module represented
> by the Module Record referencingModule.

Instead of the ECMAScript spec definining it, it's left to environments to
define it appropriately for the environment, since different environments
have different design constraints and criteria. For instance, [this part of
the WHAT-WG HTML spec][2] covers using modules on the web (drawing on
various underlying initiatives such as [`import()`][3] and
[`import.meta`][4]). (In this initial version, unsurprisingly, module
specifiers are essentially URLs, with the requirement [for now] that
relative URLs must start with `/`, `./`, or `../` so that "bare" relative
URLs can be given meaning down-the-line.)

So if you want a special token for "root," that will be an
environment-specific request, not something for TC39.

Of course, TC39 could define some syntax (outside the *ModuleSpecifier*)
that says "work from the root" while still leaving it up to the environment
what "the root" is, but there's no particular reason to do that rather than
leaving it to environments to handle as part of the *ModuleSpecifier*.

-- T.J. Crowder

[1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
[2]:
https://html.spec.whatwg.org/#integration-with-the-javascript-module-system
[3]: https://tc39.github.io/proposal-dynamic-import/
[4]: https://tc39.github.io/proposal-import-meta/