> 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
