Endorse an unambiguous syntax for ES2015 modules

martin heidegger martin.heidegger at gmail.com
Thu Sep 29 07:48:50 UTC 2016


> 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 <d at domenic.me> wrote:

> From: martin heidegger [mailto:martin.heidegger at gmail.com]
>
> > 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160929/7c9f1bde/attachment-0001.html>


More information about the es-discuss mailing list