Endorse an unambiguous syntax for ES2015 modules

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Endorse an unambiguous syntax for ES2015 modules

Martin Heidegger
I would like to ask this again, in more depth than on twitter ...

The ES6 module support proposal of Node-eps currently states:

Note: While the ES2015 specification does not forbid this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @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.

Unambiguous ES6 module support is imho:

... 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 regards
Martin Heidegger

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important http://es2015-node.js.org/#changing-the-es2015-specification
P.P.S.: Thanks to Matthew Phillips for pointing me to es-discuss.

 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Endorse an unambiguous syntax for ES2015 modules

Domenic Denicola

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:[hidden email]] On Behalf Of martin heidegger
Sent: Tuesday, September 6, 2016 23:17
To: [hidden email]
Subject: Endorse an unambiguous syntax for ES2015 modules

 

I would like to ask this again, in more depth than on twitter ...

 

The ES6 module support proposal of Node-eps currently states:

 

Note: While the ES2015 specification does not forbid this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @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.

 

Unambiguous ES6 module support is imho:

 

... 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 regards
Martin Heidegger

 

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important http://es2015-node.js.org/#changing-the-es2015-specification

P.P.S.: Thanks to Matthew Phillips for pointing me to es-discuss.

 

 

 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Endorse an unambiguous syntax for ES2015 modules

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

On Tue, Sep 6, 2016 at 8:24 PM, Domenic Denicola <[hidden email]> wrote:

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:[hidden email]] On Behalf Of martin heidegger
Sent: Tuesday, September 6, 2016 23:17
To: [hidden email]
Subject: Endorse an unambiguous syntax for ES2015 modules

 

I would like to ask this again, in more depth than on twitter ...

 

The ES6 module support proposal of Node-eps currently states:

 

Note: While the ES2015 specification does not forbid this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @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.

 

Unambiguous ES6 module support is imho:

 

... 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 regards
Martin Heidegger

 

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important http://es2015-node.js.org/#changing-the-es2015-specification

P.P.S.: Thanks to Matthew Phillips for pointing me to es-discuss.

 

 

 


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Endorse an unambiguous syntax for ES2015 modules

Martin Heidegger
In reply to this post by Domenic Denicola
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 regards
Martin Heidegger


On 7 September 2016 at 12:24, Domenic Denicola <[hidden email]> wrote:

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:[hidden email]] On Behalf Of martin heidegger
Sent: Tuesday, September 6, 2016 23:17
To: [hidden email]
Subject: Endorse an unambiguous syntax for ES2015 modules

 

I would like to ask this again, in more depth than on twitter ...

 

The ES6 module support proposal of Node-eps currently states:

 

Note: While the ES2015 specification does not forbid this extension, Node wants to avoid acting as a rogue agent.
Node has a TC39 representative, @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.

 

Unambiguous ES6 module support is imho:

 

... 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 regards
Martin Heidegger

 

P.S.: I have noted in a write-up of the ES6 module for Node.js integration that this would be important http://es2015-node.js.org/#changing-the-es2015-specification

P.P.S.: Thanks to Matthew Phillips for pointing me to es-discuss.

 

 

 



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Endorse an unambiguous syntax for ES2015 modules

Domenic Denicola
In reply to this post by Jordan Harband
From: Jordan Harband [mailto:[hidden email]]

> 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Endorse an unambiguous syntax for ES2015 modules

Domenic Denicola
In reply to this post by Martin Heidegger
From: martin heidegger [mailto:[hidden email]]

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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Endorse an unambiguous syntax for ES2015 modules

Martin Heidegger
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 https://github.com/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 regards
Martin Heidegger



On 7 September 2016 at 13:04, Domenic Denicola <[hidden email]> wrote:
From: martin heidegger [mailto:[hidden email]]

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



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Endorse an unambiguous syntax for ES2015 modules

Kevin Smith

I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think. 


On 12:31AM, Wed, Sep 7, 2016 martin heidegger <[hidden email]> wrote:
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 https://github.com/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 regards
Martin Heidegger



On 7 September 2016 at 13:04, Domenic Denicola <[hidden email]> wrote:
From: martin heidegger [mailto:[hidden email]]

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


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss