Add Unambiguous ES Module Grammar to the July agenda.

[jdalton]

This PR adds the Unambiguous ES Module Grammar proposal to the July agenda.

[allenwb]

@jdalton I don't see anything in the "Unambiguous ES Module Grammar Proposal" (BTW, not a technically correct description of the issue, the ECMA-262 grammars are not ambiguous) that proposes or actually requires any changes to the ECMA-262 specification.

Could you provide additional material for this agenda item that address what, if anything, you are proposing for ECMA-262

[ljharb]

The proposal says "The proposal is to require that Module source text has at least one import or export statement." - my understanding is that the goal is to make it impossible for any file to correctly parse as both a Script and a Module, thus reducing/removing parsing ambiguity.

[allenwb]

Yes, but you need to address why this is a ECMA-262 problem (rather than a Node problem) that requires a ECMA-262 fix.

Also note, that a Node CJS module semantically is not an ECMAScript Script. This proposal does nothing to prevent a actual Script from being misinterpreted as a CJS module or visa-versa. Why isn't that addressed.

[bterlson]

Sounds like a third top-level goal symbol, ModuleOrScript, which is a cover grammar for both Module and Script, with a static semantics that checks for the presence of imports/exports and if so, re-parses as Module, and otherwise re-parses as Script. I am also not sure why this need be an ECMA-262 problem other than I that I could make an argument that other tools/environments might want to accomplish a similar feat.

[ljharb]

This isn't about detection - my understanding is that the desired outcome of the proposal is that a file without any import or export declarations is always only a Script and a file with them is always only a Module. The detection mechanism is not a TC39 problem, but the current ambiguity - that a file that parses as a Script will also parse as a Module (but with silently different semantics), and a file that parses as a Module might parse as a Script - is problematic, and is a TC39 concern.

[allenwb]

@bterlson Right, this could be done but it still would not distinguish a CJS module from a Script.

We really need to know why this is a ECMA-262 problem and if it is we need a comprehensive solution.

BTW, currently ECMA-262 leaves it up to an implementation to determine for each source "file" whether to parse it as a Script or Module. Nothing in the spec. stops an implementation (eg, Node) from making that determination based upon the presence of import or export and announcing that to the world. TC39 permission isn't required.

[jeffmo]

Yes, but you need to address why this is a ECMA-262 problem (rather than a Node problem) that requires a ECMA-262 fix.

Agree the proposal should at least address this, but I think it's fairly clear why this is an ECMA-262 problem: because it is a Node problem.

Specifically: I don't think framing this in an us vs them way is going to be very productive. We need to work together here and talking about options is a way to do that.

[allenwb]

@ljharb This seems to be driven by Node issues yet CJS modules are not Scripts (in particularly, many semantic differences for top level declarations). How does distingishing ES Modules from ES Scripts address the Node problem.

[ljharb]

It addresses one of the problems in the entire ecosystem which was introduced by a different parsing goal: which is indeed, detection. console.log(typeof this) is both a valid Module and a valid Script (and also a valid CJS module, but focusing on the differences between Script and CJS isn't useful), and that fact is problematic.

The presence of import and/or export makes a file unambiguously a Module, but their absence does not make a file unambiguously a non-Module (what it might be at that point, Script vs CJS vs other, is utterly irrelevant). imo this is an inherent flaw in the Module parsing goal, arguably even a spec bug, and my understanding is that this proposal is attempting to fix it.

[allenwb]

@ljharb Not a bug, but a considered TC39 decision made in support of some specific goals.

But, more to the point these are exactly the sort of issues and concerns that should be covered by this agenda item. I'm hoping that there will be a document addressing them available prior to the meeting.

[leobalter]

How does distingishing ES Modules from ES Scripts address the Node problem.

This is an important question that needs to be addressed by this proposal. Even though, it does not seem to be a blocking condition to move towards on the staged process, as I don't expect the proposal to solve everything rightfully on stage 0.

But, more to the point these are exactly the sort of issues and concerns that should be covered by this agenda item. I'm hoping that there will be a document addressing them available prior to the meeting

I believe using that proposals' issues page is a good way to reach them out with everything we want to have all set before the meeting. As this current issue might get overwhelmed by different points to be discussed.

[jdalton]

Thanks all!

@bterlson

I am also not sure why this need be an ECMA-262 problem other than I that I could make an argument that other tools/environments might want to accomplish a similar feat.

One example is Microsoft packaged web apps.

@allenwb

Yes, but you need to address why this is a ECMA-262 problem (rather than a Node problem) that requires a ECMA-262 fix.

I'll continue to work with @bmeck on a ECMA specific document for this.

I'm hoping that there will be a document addressing them available prior to the meeting.

Will do.

[leobalter]

@jdalton something I learned from the last meeting is that it's helpful if the docs are ready ~7 days before the meetings, so it gives a chance for every other representative to read and provide a follow up.

I'll keep track on this item so I can try to identify any other pre-meeting questions to register.

[jdalton]

@leobalter Sounds good. Thank you!

[domenic]

console.log(typeof this) is both a valid Module and a valid Script (and also a valid CJS module, but focusing on the differences between Script and CJS isn't useful), and that fact is problematic.

How is this not useful? This is the very crux of the problem. Your tiny example script behaves differently in CJS and in Script: in Script it logs the global, whereas in CJS it logs the exports object.

I agree with the others that this is not something to be solved by changes to the language, and the lack of understanding that CJS vs. Script itself suffers from this problem is a good emphasis to that point.

[ljharb]

I agree Script vs CJS suffers from this problem. I also believe that Modules should not ideally suffer from this problem, and this proposal appears to be attempting to address that.

[zenparsing]

And the ES6 relitigation time-wasting continues...

[ljharb]

Everything is always subject to achieving a different consensus, absent web compat issues. It's not wasting time.

[zenparsing]

It's not wasting time for privileged individuals with time to waste.

[allenwb]

@ljharb ES modules originally included syntax to distinguish them from scripts. After consideration and discussion TC39 decided to remove that syntax. There were strong motivations for that decision. Any proposal to reintroduce that sort of syntactic distinction needs to revisit the arguments that lead to its removal. Those discussions should be documented in TC39 meeting notes. Probably in the 2012-2013 time frame.

[jeffmo]

@allenwb: Are you referring to the module { ... } syntax?

[allenwb]

@jeffmo yes

[bterlson]

Why is it important to consider the distinction between Scripts and CommonJS modules? If TC39 decided that there were a blessed way to know for sure whether some source text were Module or Script, I can't see how node wouldn't be able to use it to discriminate ES6 module vs. CommonJS module.

[concavelenz]

"module" vs. "script" is not Node specific problem. It is a tooling
problem. "modules" must be loaded differently than "scripts" on the web or
with Node. There are no end to the complications that the ambiguity
between the two causes.

Personally, I would like to see both this proposed change AND the file
extension convention of ".m.js" in play.

On Wed, Jun 15, 2016 at 4:15 PM, Brian Terlson notifications@github.com
wrote:

Why is it important to consider the distinction between Scripts and
CommonJS modules? If TC39 decided that there were a blessed way to know for
sure whether some source text were Module or Script, I can't see how node
wouldn't be able to use it to discriminate ES6 module vs. CommonJS module.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#194 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABMDKjxLFZ1C2YqXfY3ryaHotGDf84fNks5qMIeVgaJpZM4I16He
.

[zenparsing]

"modules" must be loaded differently than "scripts" on the web or with Node.

I'm not aware of any problems for browsers, since the module/script thing is determined by how the file is loaded (<script type='module'> or import loads modules). Is there some other problem?

[bmeck]

@zenparsing import "/scriptfrom2000.php"; may still function, but may have incorrect behavior; it is not purely for modules depending on your view of what/who controls the source text's intent: is it coming from the consumer (dynamic), or the source text/metadata (generally static).

I lean on the side of source text/metadata is the authority on what defined the behavior of source text. This is amplified by not having a standard metadata method to affect things for ES (we have directives, but those are not favorable).