detecting JS language mode for tools

John Barton johnjbarton at google.com
Fri Jan 24 12:29:59 PST 2014


On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com>wrote:

> I should have also included:
>
> 2A) Hopefully, overtime, the old script syntactic goal will fade from use,
> and the module goal will become the norm for new code.
>

Now here is a reason, finally, for all the extra complexity the two goals
cause.

If we want to kill script, let's not stab it with a dull pencil. Let's make
Loader and System be modules, not globals. Then you cannot load modules
with <script>, only with <module>.



>
>
> On Jan 24, 2014, at 11:38 AM, Allen Wirfs-Brock wrote:
>
>
> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> 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/20140124/103ff6ab/attachment-0001.html>


More information about the es-discuss mailing list