<p dir="ltr">I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think.  </p>
<br><div class="gmail_quote"><div dir="ltr">On 12:31AM, Wed, Sep 7, 2016 martin heidegger <<a href="mailto:martin.heidegger@gmail.com">martin.heidegger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> <span style="color:rgb(80,0,80);font-size:12.8px">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).</span><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div></div><div dir="ltr"><div>I might be overseeing something but <a href="https://github.com/bmeck/UnambiguousJavaScriptGrammar#example" target="_blank">https://github.com/bmeck/UnambiguousJavaScriptGrammar#example</a> ← 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.</div><div><br></div><div>(Nothing indicates to me that using the word "hole in the spec" is an inappropriate representation of the situation ...)<br><br>> <span style="color:rgb(80,0,80);font-size:12.8px">Browsers have chosen to solve this with out-of-band metadata...</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">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."</span></div><div><br></div><div>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.</div><div><br></div><div><font color="#500050"><span style="font-size:12.8px">> ... </span></font><span style="color:rgb(80,0,80);font-size:12.8px">will disagree with your assessment ...</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">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. </span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">best regards</span></div></div><div dir="ltr"><div><span style="color:rgb(80,0,80);font-size:12.8px">Martin Heidegger</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 September 2016 at 13:04, Domenic Denicola <span dir="ltr"><<a href="mailto:d@domenic.me" target="_blank">d@domenic.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>From: martin heidegger [mailto:<a href="mailto:martin.heidegger@gmail.com" target="_blank">martin.heidegger@gmail.com</a>]<br>
<br>
</span><span>> Thank you for taking the time to answer. For some reason it seems like<br>
> I framed it to be a Node.js specific issue. In my understanding the current ES2015 module specification is ambiguous regarding backwards compatibility.<br>
> Node.js or Browser that surely is an issue for the implementers?! This<br>
> 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.<br>
<br>
</span><span>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).<br>
<br>
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".)<br>
<br>
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.<br>
<br>
</span><span>> 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.).<br>
<br>
</span><span>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!)<br>
 <br>
</span><span>> 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.<br>
<br>
</span><div><div>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.<br>
<br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>