Endorse an unambiguous syntax for ES2015 modules

Kevin Smith zenparsing at gmail.com
Thu Sep 29 03:12:56 UTC 2016


I suggest re-reading Domenic's two replies; they quite exhaust the topic, I
think.

On 12:31AM, Wed, Sep 7, 2016 martin heidegger <martin.heidegger at gmail.com>
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 <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.
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160929/5d1adabd/attachment.html>


More information about the es-discuss mailing list