Endorse an unambiguous syntax for ES2015 modules
As has been discussed many times, TC39 doesn’t need to endorse Node placing host-environment-specific restrictions on its inputs. They already impose restriction that CJS modules be FunctionBody, instead of the top-level Script production in the spec. Similarly, they can create their own grammar production, ModuleWithRequiredImportOrExport (or whatever), and impose that on their users as a second alternate restriction.
What many people in TC39 will not support is placing an unnecessary restriction on all users of JavaScript. That is against the goal of our job as a host-environment-agnostic language. We supply the building blocks, and different host environments do different things with those. E.g. HTML has a nonstandard entry point for inline event handlers (onload=""), but we don’t codify that restriction into the language in some way; that’s just not our job and would be counterproductive to environments like Node which don’t need to support inline event handlers.
Furthermore, at least several members of TC39 see a file extension as a tried-and-true way of communication out of band metadata, and think that’s a fine way to go. There are other possibilities, e.g. using import for ES modules and require for CommonJS ones (along with a command-line switch for the entry module). So even if you’re talking about endorsing Node.js requiring ModuleWithRequiredImportOrExport for their users, I don’t think you’ll find a consensus among TC39 to “endorse” such an approach, since several members think it’s a less elegant solution than other possibilities.
An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.).
since several members think it’s a less elegant solution than other possibilities.
Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction.
best Martin Heidegger
[1] I wrote this: martinheidegger/es6modules
From: Jordan Harband [mailto:ljharb at gmail.com]
An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
Sure. But you can extrapolate from the many previous conversations with committee members about this proposal what will happen when it is presented. Similar to how if I planned to propose adding the C language's type system to JavaScript, it would be fair to make guesses about how such a proposal would go, and whether it would achieve consensus, based on previously-expressed opinions by committee members about types in JavaScript.
From: martin heidegger [mailto:martin.heidegger at gmail.com]
Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This is not correct. There is nothing backward-incompatible about adding a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).
It's true that there are source strings that match both the Script and Module goals. But this is not a problem for backward-compatibility, and calling it "ambiguous" is a stretch. (Is the string "Hello, world!" a text/plain or text/html file? It's "ambiguous", I guess, but no known software has problems with this "ambiguity".)
So the specific proposal of "unambiguous module grammar" is very much a Node.js specific issue. It's even worse than that: it's a Node.js specific issue where the proposal is to turn that Node.js specific issue into a restriction placed on all host environments, not just Node.js.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.).
Yes, exactly. Browsers have chosen to solve this with out-of-band metadata (import only works on modules, not scripts, and <script type="module"> is there for the entry module). Node.js could do a similar solution (import only works on ES modules, not CJS modules, and node --module is there for the entry module). Or with a different out-of-band solution (such as .mjs). Or with a restriction on the source text (requiring "use module" or export {} or...). It's not the committee's job to endorse a solution for each host environment. And it's certainly not the committee's job to add artificial restrictions to the language so that the restrictions in place in one host environment are also enforced by other host environments. (Otherwise, Node would never be allowed to use FunctionBody in the first place as its goal symbol!)
Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction.
I think you'll find that reasonable people, including many committee members, will disagree with your assessment of what is better and cleaner. Furthermore, since agreement on this subject is not really germane to the committee's focus (since it is a question for host environments, not the base language) there's no a lot of urgency for the committee members to force each other into agreement. Instead, the various people in charge of the host environments are best off making their own decisions. If they find the committee's input valuable, they're welcome to consult committee members, but given that reasonable people can disagree, you'll likely get different suggestions based on which committee members you talk to.
This is not correct. There is nothing backward-incompatible about adding
a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).
I might be overseeing something but bmeck/UnambiguousJavaScriptGrammar#example ← The examples given here are incompatibilities. (right?!) In browsers the "this" would be "window" instead of "global". Any text editor, any tool that tries to work with a given .js file would need to decide which approach to use for processing (i.e. code-completion). With unspecified out-of-band metadata editors would have a hard time to guess the format as well. Browsers, Node.js and editors (have to) care about this non-specification.
(Nothing indicates to me that using the word "hole in the spec" is an inappropriate representation of the situation ...)
Browsers have chosen to solve this with out-of-band metadata...
This basically requires any other solution to play ball. If the TC39
doesn't consider an unambiguous specification then I think it would be
important to specify another set of out-of-band metadata recommendations in
the interest of the JavaScript ecosystem. i.e. something like "Files SHOULD
treat .js files having the former logic and .esm files as having the new
logic. A mime-type application/es-module CAN also clearly indicate the
content type and when used HAS to be treated with a higher priority than
the file ending."
This would be important for browser as well: They could judge whether a loaded file is intended to be an esm or not and show an error message.
... will disagree with your assessment ...
I am open to be enlightened. I consider the TC39 members to be reasonable, intelligent persons. A lack of agreement shows just to me that there is a lack of information to all parties, keeps them form being decisive about it.
best Martin Heidegger
I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think.
I would like to ask this again, in more depth than on twitter twitter.com/leichtgewicht/status/773348056775266304 ...
The ES6 module support proposal of Node-eps currently states nodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module :
Note: While the ES2015 specification does not forbid www.ecma-international.org/ecma-262/6.0/#sec-forbidden-extensions this extension, Node wants to avoid acting as a rogue agent. Node has a TC39 representative, @bmeck bmeck, to champion this proposal. *A specification change or at least an official endorsement of this Node proposal would be welcomed.*If a resolution is not possible, this proposal will fallback to the previous .mjs file extension proposal nodejs/node-eps/blob/5dae5a537c2d56fbaf23aaf2ae9da15e74474021/002-es6-modules.md#51-determining-if-source-is-an-es-module.
Unambiguous ES6 module support is imho nodejs/node-eps#39:
... an embarrassingly simple solution that would fix a major problem by
creating a little effort for a minority of users and makes everyone's life better.
... so: What is the problem for the TC39 to doing the endorse this effort?
best Martin Heidegger
P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important es2015-node.js.org/#changing-the-es2015-specification P.P.S.: Thanks to Matthew Phillips twitter.com/matthewcp/status/773351980068638720 for pointing me
to es-discuss.
An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
From: martin heidegger [mailto:martin.heidegger at gmail.com]
Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This is not correct. There is nothing backward-incompatible about adding a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).
It's true that there are source strings that match both the Script and Module goals. But this is not a problem for backward-compatibility, and calling it "ambiguous" is a stretch. (Is the string "Hello, world!" a text/plain or text/html file? It's "ambiguous", I guess, but no known software has problems with this "ambiguity".)
So the specific proposal of "unambiguous module grammar" is very much a Node.js specific issue. It's even worse than that: it's a Node.js specific issue where the proposal is to turn that Node.js specific issue into a restriction placed on all host environments, not just Node.js.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.).
Yes, exactly. Browsers have chosen to solve this with out-of-band metadata (import only works on modules, not scripts, and <script type="module"> is there for the entry module). Node.js could do a similar solution (import only works on ES modules, not CJS modules, and node --module is there for the entry module). Or with a different out-of-band solution (such as .mjs). Or with a restriction on the source text (requiring "use module" or export {} or...). It's not the committee's job to endorse a solution for each host environment. And it's certainly not the committee's job to add artificial restrictions to the language so that the restrictions in place in one host environment are also enforced by other host environments. (Otherwise, Node would never be allowed to use FunctionBody in the first place as its goal symbol!)
Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction.
I think you'll find that reasonable people, including many committee members, will disagree with your assessment of what is better and cleaner. Furthermore, since agreement on this subject is not really germane to the committee's focus (since it is a question for host environments, not the base language) there's no a lot of urgency for the committee members to force each other into agreement. Instead, the various people in charge of the host environments are best off making their own decisions. If they find the committee's input valuable, they're welcome to consult committee members, but given that reasonable people can disagree, you'll likely get different suggestions based on which committee members you talk to.
As has been discussed many times, TC39 doesn’t need to endorse Node placing host-environment-specific restrictions on its inputs. They already impose restriction that CJS modules be FunctionBody, instead of the top-level Script production in the spec. Similarly, they can create their own grammar production, ModuleWithRequiredImportOrExport (or whatever), and impose that on their users as a second alternate restriction.
What many people in TC39 will not support is placing an unnecessary restriction on all users of JavaScript. That is against the goal of our job as a host-environment-agnostic language. We supply the building blocks, and different host environments do different things with those. E.g. HTML has a nonstandard entry point for inline event handlers (onload=""), but we don’t codify that restriction into the language in some way; that’s just not our job and would be counterproductive to environments like Node which don’t need to support inline event handlers.
Furthermore, at least several members of TC39 see a file extension as a tried-and-true way of communication out of band metadata, and think that’s a fine way to go. There are other possibilities, e.g. using import for ES modules and require for CommonJS ones (along with a command-line switch for the entry module). So even if you’re talking about endorsing Node.js requiring ModuleWithRequiredImportOrExport for their users, I don’t think you’ll find a consensus among TC39 to “endorse” such an approach, since several members think it’s a less elegant solution than other possibilities.
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of martin heidegger Sent: Tuesday, September 6, 2016 23:17 To: es-discuss at mozilla.org Subject: Endorse an unambiguous syntax for ES2015 modules
I would like to ask this again, in more depth than on twittertwitter.com/leichtgewicht/status/773348056775266304 ...
The ES6 module support proposal of Node-eps currently statesnodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module:
Note: While the ES2015 specification does not forbidwww.ecma-international.org/ecma-262/6.0/#sec-forbidden-extensions this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @bmeckbmeck, to champion this proposal.
A specification change or at least an official endorsement of this Node proposal would be welcomed. If a resolution is not possible, this proposal will fallback to the previous .mjs file extension proposalnodejs/node-eps/blob/5dae5a537c2d56fbaf23aaf2ae9da15e74474021/002-es6-modules.md#51-determining-if-source-is-an-es-module.
Unambiguous ES6 module support is imhonodejs/node-eps#39:
... an embarrassingly simple solution that would fix a major problem by creating a little effort for a minority of users and makes everyone's life better.
... so: What is the problem for the TC39 to doing the endorse this effort?
best Martin Heidegger
P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important es2015-node.js.org/#changing-the-es2015-specification P.P.S.: Thanks to Matthew Phillipstwitter.com/matthewcp/status/773351980068638720 for pointing me to es-discuss.
I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think.
From: Jordan Harband [mailto:ljharb at gmail.com]
An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
Sure. But you can extrapolate from the many previous conversations with committee members about this proposal what will happen when it is presented. Similar to how if I planned to propose adding the C language's type system to JavaScript, it would be fair to make guesses about how such a proposal would go, and whether it would achieve consensus, based on previously-expressed opinions by committee members about types in JavaScript.
Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.).
since several members think it’s a less elegant solution than other possibilities.
Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction.
best Martin Heidegger
[1] I wrote this: martinheidegger/es6modules
This is not correct. There is nothing backward-incompatible about adding
a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).
I might be overseeing something but bmeck/UnambiguousJavaScriptGrammar#example ← The examples given here are incompatibilities. (right?!) In browsers the "this" would be "window" instead of "global". Any text editor, any tool that tries to work with a given .js file would need to decide which approach to use for processing (i.e. code-completion). With unspecified out-of-band metadata editors would have a hard time to guess the format as well. Browsers, Node.js and editors (have to) care about this non-specification.
(Nothing indicates to me that using the word "hole in the spec" is an inappropriate representation of the situation ...)
Browsers have chosen to solve this with out-of-band metadata...
This basically requires any other solution to play ball. If the TC39
doesn't consider an unambiguous specification then I think it would be
important to specify another set of out-of-band metadata recommendations in
the interest of the JavaScript ecosystem. i.e. something like "Files SHOULD
treat .js files having the former logic and .esm files as having the new
logic. A mime-type application/es-module CAN also clearly indicate the
content type and when used HAS to be treated with a higher priority than
the file ending."
This would be important for browser as well: They could judge whether a loaded file is intended to be an esm or not and show an error message.
... will disagree with your assessment ...
I am open to be enlightened. I consider the TC39 members to be reasonable, intelligent persons. A lack of agreement shows just to me that there is a lack of information to all parties, keeps them form being decisive about it.
best Martin Heidegger
From: Jordan Harband [mailto:ljharb at gmail.com]
An alternative answer to "What is the problem for the TC39 to doing the endorse this effort?" is, it hasn't been presented to the committee yet. So, it's a little soon to declare that there is or is not a consensus, or that TC39 is doing or not doing anything about it. The committee hasn't been given the chance to consider it yet.
Sure. But you can extrapolate from the many previous conversations with committee members about this proposal what will happen when it is presented. Similar to how if I planned to propose adding the C language's type system to JavaScript, it would be fair to make guesses about how such a proposal would go, and whether it would achieve consensus, based on previously-expressed opinions by committee members about types in JavaScript.
Thank you for taking the time to answer. For some reason it seems like I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility. Node.js or Browser that surely is an issue for the implementers?! This seems like a hole/bug/problem in the specification to me. (Please correct me if I am wrong). And it also seems to me like this is a serious issue.
This problem can be solved in my understanding either by adding out-of-band metadata (file extension, mime-type, ...) or within the file ( shebang like comments, "use strict" like spec etc.).
since several members think it’s a less elegant solution than other possibilities.
Considering the other options I - with a lot of effort [1] - can not think of a better, cleaner solution for the ecosystem. You write that "several members" think otherwise: I hope it an agreement for the best way to fix that can be found and that agreement is used as endorsement (or not) for implementing the logic in Node.js. It would be important to know if they work into the right direction.
best Martin Heidegger
[1] I wrote this: martinheidegger/es6modules
This is not correct. There is nothing backward-incompatible about adding
a new top-level grammar goal. And the new grammar goal has even less impact on Node.js, which does not use the existing grammar goal that the spec gives them (Script).
I might be overseeing something but bmeck/UnambiguousJavaScriptGrammar#example ← The examples given here are incompatibilities. (right?!) In browsers the "this" would be "window" instead of "global". Any text editor, any tool that tries to work with a given .js file would need to decide which approach to use for processing (i.e. code-completion). With unspecified out-of-band metadata editors would have a hard time to guess the format as well. Browsers, Node.js and editors (have to) care about this non-specification.
(Nothing indicates to me that using the word "hole in the spec" is an inappropriate representation of the situation ...)
Browsers have chosen to solve this with out-of-band metadata...
This basically requires any other solution to play ball. If the TC39
doesn't consider an unambiguous specification then I think it would be
important to specify another set of out-of-band metadata recommendations in
the interest of the JavaScript ecosystem. i.e. something like "Files SHOULD
treat .js files having the former logic and .esm files as having the new
logic. A mime-type application/es-module CAN also clearly indicate the
content type and when used HAS to be treated with a higher priority than
the file ending."
This would be important for browser as well: They could judge whether a loaded file is intended to be an esm or not and show an error message.
... will disagree with your assessment ...
I am open to be enlightened. I consider the TC39 members to be reasonable, intelligent persons. A lack of agreement shows just to me that there is a lack of information to all parties, keeps them form being decisive about it.
best Martin Heidegger
I would like to ask this again, in more depth than on twitter twitter.com/leichtgewicht/status/773348056775266304 ...
The ES6 module support proposal of Node-eps currently states nodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module :
Unambiguous ES6 module support is imho nodejs/node-eps#39:
... an embarrassingly simple solution that would fix a major problem by
... so: What is the problem for the TC39 to doing the endorse this effort?
best Martin Heidegger
P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important es2015-node.js.org/#changing-the-es2015-specification P.P.S.: Thanks to Matthew Phillips twitter.com/matthewcp/status/773351980068638720 for pointing me
to es-discuss.