Re: Module syntax

`import foo from "foo";` reads to the quick eye as "import the symbol named foo from the module named 'foo'" -- but that's not actually what it means (wrapped curlies be damned!). I think the syntax would read much less confusingly if we made use of a `default` keyword to signify better what's h

Re: Module syntax

> > > Bikeshedding: > > Well, here comes a fun thread... > > Bikeshedding *is* fun : ) FWIW, I've implemented a parser for curly-free syntax and it does introduce some minor parsing difficulties on the export side. If we had lexical modules, then this: export module as ... could be a valid

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: May 21, 22, 23 TC39 Meeting Notes

Dmitry Soshnikov wrote: I see. Yeah.. it looks at least weird (even if not lexical, which, yeah -- bad, why still ugly string names?), and I agree it could lead to a fundamental mistake since will stick for years until ES7. The fundamental mistake would be rejecting the detailed rationale for

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: Module syntax

On Mon, Jun 3, 2013 at 1:55 PM, Juan Ignacio Dopazo wrote: > Now that it's been decided that braces are not a form of destructuring and > the colon replaced with `as`, what's the benefit of using braces? Why not > this previous proposal? > > import foo as foofoo from "foo"; > > import "bar" as bar

Re: Module syntax

On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer wrote: > Bikeshedding: Well, here comes a fun thread... > Rationale: > – Reducing the grawlix factor. > – Making non-default imports more convenient – which I assume will happen > more often(?) That's what this comes down to: do you expect the com

Re: Module syntax

On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo wrote: > Now that it's been decided that braces are not a form of destructuring and > the colon replaced with `as`, what's the benefit of using braces? Why not > this previous proposal? > > import foo as foofoo from "foo"; > > import "bar" as ba

Re: May 21, 22, 23 TC39 Meeting Notes

I see. Yeah.. it looks at least weird (even if not lexical, which, yeah -- bad, why still ugly string names?), and I agree it could lead to a fundamental mistake since will stick for years until ES7. Thanks for the original thread, will take a detailed look, but from the first pass it seems I agre

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: Module syntax

Now that it's been decided that braces are not a form of destructuring and the colon replaced with `as`, what's the benefit of using braces? Why not this previous proposal? import foo as foofoo from "foo"; import "bar" as bar; Juan ___ es-discuss maili

Re: Module syntax

if ``` function x() {} export default x; ``` works thought, that ain't any different from returning function expression where you cannot reuse that function if not inside the function itself. It does not look like a big lost but more similar to expression logic we are use to with JS ... or, is i

Re: Module syntax

+1 as soon as the syntax is slightly different from NPM/AMD makes sense to have less ambiguity and a better definition. export default looks good here too On Mon, Jun 3, 2013 at 12:57 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I really dislike `export =`. It looks like it sho

Re: Module syntax

> `export default` is perfect IMO. It also conceptually fits better with how > default exports work. (I.e., they're *default* exports, they're not the > entirety of the exports. They don't overwrite the module instance object, > in the fashion that `module.exports =` does.) > > A potential problem

Re: Module syntax

On Mon, Jun 3, 2013 at 3:57 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I really dislike `export =`. It looks like it should be creating a global > variable named `export`. > > `export default` is perfect IMO. It also conceptually fits better with how > default exports work. (I.e.

Re: Module syntax

We may be able to have both: convenient default imports and convenient non-default imports, if we bring back `export =` (which, IIRC, has been proposed a while ago) and introduce `import =` as an analog. Example: module "jquery" { export = { ... }; } import $ = "jquery"; Not co

Re: Module syntax

I was corresponding with Axel about what's possible without ambiguity, and he pushed for brace elimination noting that 'default' is a reserved word. This led to me remembering the export = ... form, more concise than export default ... -- not that "more concise" must win, but it seems worth a b

RE: Module syntax

I really dislike `export =`. It looks like it should be creating a global variable named `export`. `export default` is perfect IMO. It also conceptually fits better with how default exports work. (I.e., they're *default* exports, they're not the entirety of the exports. They don't overwrite the

Re: Module syntax

On Jun 3, 2013, at 20:41 , Rick Waldron wrote: > On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote: >> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote: >> Bikeshedding: I generally like the module syntax, but I’d always omit the >> braces and use `import default` for importing the

Re: Module syntax

On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote: > Bikeshedding: I generally like the module syntax, but I’d always omit the > braces and use `import default` for importing the default export of a > module. > >From the wiki: module "foo" { export default function() { console.log("hello

Re: Module syntax

On Mon, Jun 3, 2013 at 2:40 PM, Axel Rauschmayer wrote: > On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote: > >> Bikeshedding: I generally like the module syntax, but I’d always omit the >> braces and use `import default` for importing the default export of a >> module. >> > > From the wik

Re: Module syntax

> On Mon, Jun 3, 2013 at 1:29 PM, Axel Rauschmayer wrote: > Bikeshedding: I generally like the module syntax, but I’d always omit the > braces and use `import default` for importing the default export of a module. > > From the wiki: > > module "foo" { > export default function() { console.log

Re: May 21, 22, 23 TC39 Meeting Notes

Yehuda Katz wrote: On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg > wrote: On 2 June 2013 22:19, Dmitry Soshnikov mailto:dmitry.soshni...@gmail.com>> wrote: >> 4.10 Modules >> >> STH: Progress since last meeting. Discuss “module naming”, “naming

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

Module syntax

Bikeshedding: I generally like the module syntax, but I’d always omit the braces and use `import default` for importing the default export of a module. Rationale: – Reducing the grawlix factor. – Making non-default imports more convenient – which I assume will happen more often(?) -- Dr. Axel

Re: May 21, 22, 23 TC39 Meeting Notes

On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg wrote: > On 2 June 2013 22:19, Dmitry Soshnikov wrote: > >> 4.10 Modules > >> > >> STH: Progress since last meeting. Discuss “module naming”, “naming > standard > >> modules”. > >> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules > >> ST

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: May 21, 22, 23 TC39 Meeting Notes

2013/6/2 Rick Waldron > 4.4 Proxies > > TVC’s presentation on Notification Proxies: > https://docs.google.com/file/d/0B9iYRsLxmdqUd1RsdHZtazliWmc/edit?usp=sharing > > Arguments against: > - shifts the burden from spec writers/implementors to users (need to use > shadow target even for non-frozen

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: May 21, 22, 23 TC39 Meeting Notes

On Sun, Jun 2, 2013 at 4:44 PM, Tab Atkins Jr. wrote: > >> Promises vs Monads >> >> MM: Continuing from yesterday >> >> AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl >> STH: Don’t like resolve but not willing to die on this hill. >> AR: DOM has a bunch of ad hocs APIs to do pr

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.