Re: Modules vs Scripts
On Sun, Nov 17, 2013 at 2:23 PM, Matthew Robb matthewwr...@gmail.com wrote: I like it. If there is a desire to stay closer to script I could see script module and script module= Has to be script type=module otherwise it would execute in legacy clients. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 18, 2013 7:17 AM, Brian Di Palma off...@gmail.com wrote: Correct me if I'm wrong David but module import/exports are not dynamic which allows tooling/IDEs to be more intelligent and programmers to easily understand what dependencies a module has/provides? Yes, that's correct, if I guess correctly at what you mean by dynamic. Sam On Sat, Nov 16, 2013 at 8:30 AM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote: Could someone help me understand why two goals for parsing JS is a good thing? Hm, it sounds like you've assumed a conclusion already. Let me try to explain anyway. Scripts are for synchronous loading and evaluation; modules are for asynchronous loading and evaluation. The former is not allowed to import, which triggers I/O. The latter is allowed to import. There was always going to have to be a syntactic split. But there's more. I'll be explaining at this week's TC39 meeting some more details about the intended model for browser integration. In short, declarative code based on modules will use the module tag (or script type=module, which will mean the same thing and allows polyfilling today). This is better than script async, which was a hopeless idea. This also works beautifully for fulfilling the promise of 1JS: a new, better initial environment in which to run top-level application code without requiring versioning. module var x = 12; // local to this module, not exported on global object import $ from jquery; // asynchronous dependency, NBD '$' in this // nope, because all globals are scoped to this module let y = 13; // yep, let works great because modules are strict /module Same number of characters as script, better semantics, better global environment, better language. If you're not excited about ES6 yet, get excited. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
You can statically analyze the module text and enumerate the complete imports and exports of the module without having to execute the module. The execution of the module will not dynamically increase it's imports/exports. For instance could you have a Math.random that decides if a dependency is required? On Nov 18, 2013 1:33 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Nov 18, 2013 7:17 AM, Brian Di Palma off...@gmail.com wrote: Correct me if I'm wrong David but module import/exports are not dynamic which allows tooling/IDEs to be more intelligent and programmers to easily understand what dependencies a module has/provides? Yes, that's correct, if I guess correctly at what you mean by dynamic. Sam On Sat, Nov 16, 2013 at 8:30 AM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote: Could someone help me understand why two goals for parsing JS is a good thing? Hm, it sounds like you've assumed a conclusion already. Let me try to explain anyway. Scripts are for synchronous loading and evaluation; modules are for asynchronous loading and evaluation. The former is not allowed to import, which triggers I/O. The latter is allowed to import. There was always going to have to be a syntactic split. But there's more. I'll be explaining at this week's TC39 meeting some more details about the intended model for browser integration. In short, declarative code based on modules will use the module tag (or script type=module, which will mean the same thing and allows polyfilling today). This is better than script async, which was a hopeless idea. This also works beautifully for fulfilling the promise of 1JS: a new, better initial environment in which to run top-level application code without requiring versioning. module var x = 12; // local to this module, not exported on global object import $ from jquery; // asynchronous dependency, NBD '$' in this // nope, because all globals are scoped to this module let y = 13; // yep, let works great because modules are strict /module Same number of characters as script, better semantics, better global environment, better language. If you're not excited about ES6 yet, get excited. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
Yes, exactly. Of course, running a module can load other modules using the Loaders API, but that doesn't add any new imports or exports to the module itself. Sam On Nov 18, 2013 8:54 AM, Brian Di Palma off...@gmail.com wrote: You can statically analyze the module text and enumerate the complete imports and exports of the module without having to execute the module. The execution of the module will not dynamically increase it's imports/exports. For instance could you have a Math.random that decides if a dependency is required? On Nov 18, 2013 1:33 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Nov 18, 2013 7:17 AM, Brian Di Palma off...@gmail.com wrote: Correct me if I'm wrong David but module import/exports are not dynamic which allows tooling/IDEs to be more intelligent and programmers to easily understand what dependencies a module has/provides? Yes, that's correct, if I guess correctly at what you mean by dynamic. Sam On Sat, Nov 16, 2013 at 8:30 AM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote: Could someone help me understand why two goals for parsing JS is a good thing? Hm, it sounds like you've assumed a conclusion already. Let me try to explain anyway. Scripts are for synchronous loading and evaluation; modules are for asynchronous loading and evaluation. The former is not allowed to import, which triggers I/O. The latter is allowed to import. There was always going to have to be a syntactic split. But there's more. I'll be explaining at this week's TC39 meeting some more details about the intended model for browser integration. In short, declarative code based on modules will use the module tag (or script type=module, which will mean the same thing and allows polyfilling today). This is better than script async, which was a hopeless idea. This also works beautifully for fulfilling the promise of 1JS: a new, better initial environment in which to run top-level application code without requiring versioning. module var x = 12; // local to this module, not exported on global object import $ from jquery; // asynchronous dependency, NBD '$' in this // nope, because all globals are scoped to this module let y = 13; // yep, let works great because modules are strict /module Same number of characters as script, better semantics, better global environment, better language. If you're not excited about ES6 yet, get excited. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 17, 2013, at 6:14 , David Herman dher...@mozilla.com wrote: Does this imply module src= ? Works either way, inline or external. (Requiring src= is one of the reasons why script async was a non-starter.) Is the value of `src` a module ID or a path? How about when packages are used (for bundling)? Is there a way to combine module IDs and packages? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer a...@rauschma.de wrote: On Nov 17, 2013, at 6:14 , David Herman dher...@mozilla.com wrote: Does this imply module src= ? Works either way, inline or external. (Requiring src= is one of the reasons why script async was a non-starter.) Is the value of `src` a module ID or a path? How about when packages are used (for bundling)? Is there a way to combine module IDs and packages? For the most part the answer to these kinds of questions is that we support all of the above, but I'd like to wait just a little bit longer before getting into details. Right now we've been focusing on providing a complete base (reflective) layer via the Loader API, which is what will be in ECMA-262; the rest is an HTML spec. (We are thinking through what pieces are necessary for the module tag to ensure we haven't missed anything in the Loader API.) I'm focused on getting ES6 out the door, but the next step after that is to start fleshing out the module spec. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
Is the value of `src` a module ID or a path? How about when packages are used (for bundling)? Is there a way to combine module IDs and packages? For the most part the answer to these kinds of questions is that we support all of the above, but I'd like to wait just a little bit longer before getting into details. Right now we've been focusing on providing a complete base (reflective) layer via the Loader API, which is what will be in ECMA-262; the rest is an HTML spec. (We are thinking through what pieces are necessary for the module tag to ensure we haven't missed anything in the Loader API.) I'm focused on getting ES6 out the door, but the next step after that is to start fleshing out the module spec. That makes sense. So, for starters, I’m guessing one will set up the module loader via a script tag (e.g. to enable bundling). Afterwards, the module tag will be used to load modules, via module IDs. Then “src” probably isn’t a good attribute name, “id” isn’t either (clashes with DOM terminology). “from” and “import” seem likely candidates. (Just for the sake of an initial rough story; I do understand that it doesn’t make sense to discuss details, yet.) Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote: Could someone help me understand why two goals for parsing JS is a good thing? Hm, it sounds like you've assumed a conclusion already. Let me try to explain anyway. Scripts are for synchronous loading and evaluation; modules are for asynchronous loading and evaluation. The former is not allowed to import, which triggers I/O. The latter is allowed to import. There was always going to have to be a syntactic split. But there's more. I'll be explaining at this week's TC39 meeting some more details about the intended model for browser integration. In short, declarative code based on modules will use the module tag (or script type=module, which will mean the same thing and allows polyfilling today). This is better than script async, which was a hopeless idea. This also works beautifully for fulfilling the promise of 1JS: a new, better initial environment in which to run top-level application code without requiring versioning. module var x = 12; // local to this module, not exported on global object import $ from jquery; // asynchronous dependency, NBD '$' in this // nope, because all globals are scoped to this module let y = 13; // yep, let works great because modules are strict /module Same number of characters as script, better semantics, better global environment, better language. If you're not excited about ES6 yet, get excited. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
Does this imply module src= ? On Sat, Nov 16, 2013 at 12:30 AM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 3:32 AM, John Barton johnjbar...@google.com wrote: Could someone help me understand why two goals for parsing JS is a good thing? Hm, it sounds like you've assumed a conclusion already. Let me try to explain anyway. Scripts are for synchronous loading and evaluation; modules are for asynchronous loading and evaluation. The former is not allowed to import, which triggers I/O. The latter is allowed to import. There was always going to have to be a syntactic split. But there's more. I'll be explaining at this week's TC39 meeting some more details about the intended model for browser integration. In short, declarative code based on modules will use the module tag (or script type=module, which will mean the same thing and allows polyfilling today). This is better than script async, which was a hopeless idea. This also works beautifully for fulfilling the promise of 1JS: a new, better initial environment in which to run top-level application code without requiring versioning. module var x = 12; // local to this module, not exported on global object import $ from jquery; // asynchronous dependency, NBD '$' in this // nope, because all globals are scoped to this module let y = 13; // yep, let works great because modules are strict /module Same number of characters as script, better semantics, better global environment, better language. If you're not excited about ES6 yet, get excited. :) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote: Does this imply module src= ? Works either way, inline or external. (Requiring src= is one of the reasons why script async was a non-starter.) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
3 this, it matches my go-back-to-1995 dreams. /be On Nov 16, 2013, at 9:14 PM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote: Does this imply module src= ? Works either way, inline or external. (Requiring src= is one of the reasons why script async was a non-starter.) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
I like it. If there is a desire to stay closer to script I could see script module and script module= On Sat, Nov 16, 2013 at 10:16 PM, Brendan Eich bren...@mozilla.com wrote: 3 this, it matches my go-back-to-1995 dreams. /be On Nov 16, 2013, at 9:14 PM, David Herman dher...@mozilla.com wrote: On Nov 16, 2013, at 7:54 AM, Matthew Robb matthewwr...@gmail.com wrote: Does this imply module src= ? Works either way, inline or external. (Requiring src= is one of the reasons why script async was a non-starter.) Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
Could someone help me understand why two goals for parsing JS is a good
thing?
On Mon, Nov 11, 2013 at 3:30 PM, John Barton johnjbar...@google.com wrote:
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter = new ErrorReporter();
var tree = new Parser(reporter, file).parseProgram(true);
return (new WrapNewObjectTransformer()).transformAny(tree);
}
It fails on 'unexpected token export'. This was unexpected by me ;-)
However it does seem consistent with the grammar in
http://wiki.ecmascript.org/doku.php?id=harmony:modules. The |export|
keyword is part of an ExportDeclaration which appears in a ModuleElement
but not in a ScriptElement. The parser believes it is parsing a Script. So
the only way to legally parse JS as a Module is as a side-effect of module
loading?
I suppose that a Script is intended to be the root of the dependency tree,
so the error message is trying to tell me You are compiling an interior
node of the dependency tree silly. But both Script and Module are things
that JS devs will want to compile. Concretely I will want to be able to
copy the contents of a JS file and paste it into a repl window to analyze
it without having it die on syntax errors because it is a module.
hth,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
