Re: Minor questions on new module BNF

I haven't played with Browserify too much myself (shame on me), but from my own understanding of it and after talking to a friend who is more familiar, yes I believe so. We "link" our modules statically on the server to build a dependency graph before we push to production. This linking step i

Re: Minor questions on new module BNF

Jeff Morrison wrote: require() is a synchronous call in to our module system, and we don't execute a given module until all of its require() dependencies have been downloaded. Hi Jeff, catching up (sorry if I missed it): do you do a browserify-style analysis for require("...") calls and hoist

Re: Minor questions on new module BNF

On 6/4/13 9:52 AM, Jason Orendorff wrote: On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison > wrote: FWIW this is what we have been doing at Facebook for a while now (over a year), and it's worked pretty well for us. We use a require() function for pulling i

Re: Minor questions on new module BNF

On Tue, Jun 4, 2013 at 8:02 AM, Domenic Denicola wrote: > From: Yehuda Katz [wyc...@gmail.com] > >> In general, expectations about side-effects that happen during module >> loading are really edge-cases. I would go as far as to say that modules that >> produce side effects during initial executi

Re: Minor questions on new module BNF

On Tue, Jun 4, 2013 at 11:44 AM, Jeff Morrison wrote: > FWIW this is what we have been doing at Facebook for a while now (over a > year), and it's worked pretty well for us. > > We use a require() function for pulling in dependencies. We then > statically extract all require() callsites for a gi

Re: Minor questions on new module BNF

On Tue, Jun 4, 2013 at 11:37 AM, Jeff Morrison wrote: > I still kinda like the idea of allowing ImportDeclarations to be > expressed anywhere inside a ScriptElement (including in its children), and > then hoisting the declaration for compilation/linking, but only executing > the dependency when

Re: Minor questions on new module BNF

FWIW this is what we have been doing at Facebook for a while now (over a year), and it's worked pretty well for us. We use a require() function for pulling in dependencies. We then statically extract all require() callsites for a given module during our build step, and use that to identify the

Re: Minor questions on new module BNF

I still kinda like the idea of allowing ImportDeclarations to be expressed anywhere inside a ScriptElement (including in its children), and then hoisting the declaration for compilation/linking, but only executing the dependency when the statement is reached at runtime. It is then a parse error

Re: Minor questions on new module BNF

On Jun 4, 2013, at 6:31 AM, Kevin Smith wrote: > Looks good, but I'm thinking that this should probably _not_ be allowed: > > import {,} from "x"; Right you are! Fixed, thanks. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail

Re: Minor questions on new module BNF

On Tuesday, June 4, 2013, Yehuda Katz wrote: > On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff > 'jason.orendo...@gmail.com');> > > wrote: > >> On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz >> >> > wrote: >> >>> I've advocated for this in the past. I believe it should be allowed. >>> >>> Separa

Re: Minor questions on new module BNF

> > > > In this case, the `import` statement is just asking the module loader to > download "someModule", but allowing the app to move on with life and not > bother executing it. This would allow an app to depend on a bunch of > top-level modules that got executed only once the user entered a parti

Re: Minor questions on new module BNF

2013/6/4 Yehuda Katz > On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff > wrote: > >> On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz wrote: >> >>> I've advocated for this in the past. I believe it should be allowed. >>> >>> Separately, I would like this form to be specified as deferring >>> execut

Re: Minor questions on new module BNF

On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff wrote: > On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz wrote: > >> I've advocated for this in the past. I believe it should be allowed. >> >> Separately, I would like this form to be specified as deferring execution >> until bindings are explicitly i

Re: Minor questions on new module BNF

On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz wrote: > I've advocated for this in the past. I believe it should be allowed. > > Separately, I would like this form to be specified as deferring execution > until bindings are explicitly imported (from another module), or a > synchronous `System.get`

RE: Minor questions on new module BNF

From: Yehuda Katz [wyc...@gmail.com] > In general, expectations about side-effects that happen during module loading > are really edge-cases. I would go as far as to say that modules that produce > side effects during initial execution are "doing it wrong", and are likely to > produce sadness.

Re: Minor questions on new module BNF

On Tue, Jun 4, 2013 at 6:29 AM, Kevin Smith wrote: > > >> Yep, agreed. (To be pedantic, it's not that it defers execution so much >> as that it doesn't force execution.) >> > > Can you explain? I would naively expect for this: > > // someModule > console.log("someModule"); > > // mai

Re: Minor questions on new module BNF

> > That appears to be disallowed; I believe > > > > "{" ImportSpecifier ("," ImportSpecifier)* ","? "}" > > > > requires at least one `ImportSpecifier`. > > Oversight. Fixed. > > Looks good, but I'm thinking that this should probably _not_ be allowed: import {,} from "x"; { Kevin } _

Re: Minor questions on new module BNF

> > Yep, agreed. (To be pedantic, it's not that it defers execution so much as > that it doesn't force execution.) > Can you explain? I would naively expect for this: // someModule console.log("someModule"); // main import "someModule"; console.log("main"); when executing m

Re: Minor questions on new module BNF

On Jun 3, 2013, at 12:24 AM, Domenic Denicola wrote: > Ah, that makes sense! It's a nice way of prohibiting `export function > foo() { }` as well, assuming inline `

Re: Minor questions on new module BNF

On Jun 3, 2013, at 9:33 AM, Yehuda Katz wrote: > On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola > wrote: > From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam > Tobin-Hochstadt > > > I would just write `import {} from "someModule";` > > That appears to be disallowed; I belie

Re: Minor questions on new module BNF

Big +1 on being able to defer execution until explicit import. It definitely seems useful to allow for control over dependency specifications separately from [potential] dependency execution. More concretely, I don't think you could do something like the following with the current module spec (

Re: Minor questions on new module BNF

Yehuda Katz wrote: I've advocated for this in the past. I believe it should be allowed. Separately, I would like this form to be specified as deferring execution until bindings are explicitly imported (from another module), or a synchronous `System.get` call is made. This would make it possi

Re: Minor questions on new module BNF

On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam > Tobin-Hochstadt > > > The idea here is that modules will typically be written in files like > "compiler/Lexer.js", where the starting gramma

RE: Minor questions on new module BNF

From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam Tobin-Hochstadt > The idea here is that modules will typically be written in files like > "compiler/Lexer.js", where the starting grammar production *is* `ModuleBody`. Ah, that makes sense! It's a nice way of prohibiting `export

Re: Minor questions on new module BNF

On Sun, Jun 2, 2013 at 11:59 PM, Domenic Denicola wrote: > Sam was saying that http://wiki.ecmascript.org/doku.php?id=harmony:modules is > up to date. If so, I'm seeing a few things missing from the BNF. It would be > great to get these clarified so people can start writing accurate transpilers.

RE: Minor questions on new module BNF

> so shouldn't `ExportDeclaration` be added to `ScriptElement`? Or perhaps to > `Statement`? Upon reflection, `Statement` is obviously incorrect, as it prevents static determination of a module's exports. `ScriptElement` still seems good though. ___ es