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
