I suggest re-reading Domenic's two replies; they quite exhaust the topic, I think.
On 12:31AM, Wed, Sep 7, 2016 martin heidegger <[email protected]> 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 <[email protected]> wrote: > >> From: martin heidegger [mailto:[email protected]] >> >> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
