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" 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" > wrote: > >> >> On Nov 18, 2013 7:17 AM, "Brian Di Palma" 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 >> wrote: >> > > On Nov 16, 2013, at 3:32 AM, John Barton >> 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 tag (or
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" wrote: > > On Nov 18, 2013 7:17 AM, "Brian Di Palma" 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 > wrote: > > > On Nov 16, 2013, at 3:32 AM, John Barton > 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 tag (or
Re: Modules vs Scripts
On Nov 18, 2013 7:17 AM, "Brian Di Palma" 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 wrote: > > On Nov 16, 2013, at 3:32 AM, John Barton 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 tag (or
Re: Modules vs Scripts
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? On Sat, Nov 16, 2013 at 8:30 AM, David Herman wrote: > On Nov 16, 2013, at 3:32 AM, John Barton 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 tag (or
Re: Modules vs Scripts
On Sun, Nov 17, 2013 at 2:23 PM, Matthew Robb wrote: > I like it. If there is a desire to stay closer to
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 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 spec. That makes sense. So, for starters, I’m guessing one will set up the module loader via a
Re: Modules vs Scripts
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer wrote: > On Nov 17, 2013, at 6:14 , David Herman wrote: > >>> Does this imply ? >> >> Works either way, inline or external. (Requiring src="" is one of the >> reasons why
Re: Modules vs Scripts
On Nov 17, 2013, at 6:14 , David Herman wrote: >> Does this imply ? > > Works either way, inline or external. (Requiring src="" is one of the reasons > why
Re: Modules vs Scripts
I like it. If there is a desire to stay closer to
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 wrote: > >> On Nov 16, 2013, at 7:54 AM, Matthew Robb wrote: >> >> Does this imply ? > > Works either way, inline or external. (Requiring src="" is one of the reasons > why
Re: Modules vs Scripts
On Nov 16, 2013, at 7:54 AM, Matthew Robb wrote: > Does this imply ? Works either way, inline or external. (Requiring src="" is one of the reasons why
Re: Modules vs Scripts
Does this imply ? On Sat, Nov 16, 2013 at 12:30 AM, David Herman wrote: > On Nov 16, 2013, at 3:32 AM, John Barton 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 tag (or
Re: Modules vs Scripts
On Nov 16, 2013, at 3:32 AM, John Barton 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 tag (or
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 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
Modules vs Scripts
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
