On Jan 24, 2014, at 9:32 AM, David Bruant wrote:

> Le 24/01/2014 18:26, John Lenz a écrit :
>> 
>> 
>> REPL is a dilemma: if you parse as module, then obtaining the last expression value is not simple. if you parse as a script, then common cut/paste fails on export/import statements.
>> 
>> My basic question remains.  As a tool owner how do I know if what I'm looking at is intended to be a Module or a Script?
> How do you know if some code is intended for the browser or Node?
> How do you know some code is intended to be used in a WebWorker and not in the main thread?
> How do you know the code won't be concatenated a "use strict" when someone else uses it?
> 
> The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)).
> If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context.

I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it.  I'm not sure if Dave would totally agree with 100% of the following but I think it is close to  what seemed to make sense in our discussions.

1) there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics.

2) A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own "file level" scope.

3) In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this.

4) but there are other situations where the intended syntactic goal of a source file need to be identifiable.  For example, when listing source files on a command-line invocations of a JavaScript engine or tool

5) Humans when reading or managing code files also need to know which kind of JS source file they are dealing with.

6) typically we use file extensions to make distinctions of this sort.

7) Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal.  .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension. 

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140124/3bb194e3/attachment-0001.html>

On Jan 24, 2014, at 9:32 AM, David Bruant wrote:

> How do you know if some code is intended for the browser or Node?
> How do you know some code is intended to be used in a WebWorker and not in the main thread?
> How do you know the code won't be concatenated a "use strict" when someone else uses it?
> 
> The code itself lacks the context in which it's being loaded (hence very defensive patterns like UMD (Universal Module Definition)).
> If you want to be exhaustive, you'll have to make an assumption or make your tool smarter about the context.

I've had some discussion with Dave Herman about this and I think there is a plausible way to handle it.  I'm not sure if Dave would totally agree with 100% of the following but I think it is close to  what seemed to make sense in our discussions.

1. there are some very good technical reasons for having two syntactic goals (script and module) corresponding to the two semantics.

2. A module with no imports and no exports is essentially a new form of top level code that is always strict mode and but has its own "file level" scope.

3. In browsers, html syntax (new attribute on script tag, etc.) can be used to distinguish the two. Dave is working on this.

4. but there are other situations where the intended syntactic goal of a source file need to be identifiable.  For example, when listing source files on a command-line invocations of a JavaScript engine or tool

5. Humans when reading or managing code files also need to know which kind of JS source file they are dealing with.

6. typically we use file extensions to make distinctions of this sort.

7. Hence, it probably makes sense to promote a convention of using a new file extension for ES6 source files that are intended to be parsed with the modules goal.  .jsm, or mjs, or something similar that is appropriately suggestive and isn't already widely used as an extension.