So I gather that the dynamic case would look like:
system.load(jqueryPath, function(m) {
system.load(shimLibPath, function(n) {
system.load(corpLibPath, function(o) {
system.load(myLibPath, function (p) {
import * from m;
import * from n;
On Thu, Mar 22, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
I guess you mean: a special form evaluated before the outer function
runs? Surely this form is not off-line.
No, before anything in the containing Program (up to the script
container) runs.
John J Barton wrote:
Brendan, your argument above makes it sound like
import x from Bar.js
does not block and thus would not starve the UI rendering. How can
that be?
While parsing (which can be done very early, as TCP segments come in,
with some assembly across boundaries required),
2. Also we are not losing static binding by having the names injected
by static syntactic forms depend on control flow dynamics.
When statically checkable constraints meet dynamic load/eval,
it isn't necessary to have a strict static/dynamic split. It would be
possible to adopt a multi-staged
Claus Reinke wrote:
When statically checkable constraints meet dynamic load/eval,
it isn't necessary to have a strict static/dynamic split. It would be
possible to adopt a multi-staged design, where there are multipe
dynamic phases, each with its own preceding static phase: no
code runs without
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
first place, since he felt programmers would get confused that it was a dynamic
assignment
On Mar 21, 2012, at 9:41 PM, Brendan Eich wrote:
Perhaps Python has the right syntax, then?
from foo.js import foo;
import foo.js as Foo;
I suppose we could. I always thought this was an awkward choice on Python's
part. The first line always reminds me of the Yinglish constructions my
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
first place, since he felt programmers would get confused that it was a
On Mar 21, 2012, at 3:28 PM, David Herman wrote:
* importing with renaming:
import { draw: drawGun }from cowboy.js,
{ draw: drawWidget } from widgets.js;
Hey Dave,
This all looks really nice! - the only thing that threw me was the export
rename – I intuitively expect the
On Wed, Mar 21, 2012 at 11:28 PM, David Herman dher...@mozilla.com wrote:
* importing with renaming:
import { draw: drawGun } from cowboy.js,
{ draw: drawWidget } from widgets.js;
The brackets don't seem necessary (at least not from a parsing
perspective). Maybe drop them?
On 22 March 2012 10:23, Peter van der Zee e...@qfox.nl wrote:
On Wed, Mar 21, 2012 at 11:28 PM, David Herman dher...@mozilla.com
wrote:
* importing with renaming:
import { draw: drawGun }from cowboy.js,
{ draw: drawWidget } from widgets.js;
The brackets don't seem
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it
in the first place, since he felt programmers would get confused that
it was a
On 22 March 2012 02:35, David Herman dher...@mozilla.com wrote:
Follow-up: I've factored out these two alternative approaches, both of
which I think are defensible.
Grammars:
http://wiki.ecmascript.org/doku.php?id=harmony:modules#syntax
Nice! One question: is there a reason why you not
On 22 March 2012 07:12, David Herman dher...@mozilla.com wrote:
On Mar 21, 2012, at 9:01 PM, Axel Rauschmayer wrote:
I like variant B, because it follows the rules:
- module = define a module
- import = extract something out of a module
As Dave already mentioned, that is my stance, too.
On 22 March 2012 07:33, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in
the first
This is great stuff. I've got a quick question about the `as` keyword.
import 'foo.js' as Foo;
Is there any reason we can't simply do
var Foo = import 'foo.js';
When looking for the source of a variable, I often search for /Foo =/ to
discern it's origin and it only seems natural that giving
/runnable.js
[5]: https://github.com/visionmedia/mocha/blob/master/lib/suite.js
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Andreas Rossberg
Sent: Thursday, March 22, 2012 07:55
To: es-discuss
Subject: Re: simpler, sweeter syntax for modules
One point
Correct me if I have any of this wrong, but modules don't need to be
callable for the jQuery use case:
// jquery.js
export function $(...) { ... }
// program.js
import $ from path/to/jquery.js;
$(#elem).whatever
We don't need node style modules-as-classes either:
//
On Mar 22, 2012, at 4:55 AM, Andreas Rossberg wrote:
One point that I haven't seen mentioned yet (and it is unrelated to syntax):
export call makes me cringe -- making modules callable is not just weird,
it seems completely future-hostile to the possibility of having parameterized
modules.
That said, it requires no more code to say:
// jquery.js
export function $(selector) { ... }
...
// client
import $ from jquery.js;
let elements = [foo, bar, baz].map($);
$(quux).style(...);
So maybe people have over-sold the importance of callable modules. In
On Mar 22, 2012, at 4:46 AM, Andreas Rossberg wrote:
Nice! One question: is there a reason why you not just define
Program ::= ModuleBody
?
No exports from a Program.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 22, 2012, at 4:48 AM, Andreas Rossberg wrote:
On 22 March 2012 07:33, Brendan Eich bren...@mozilla.org wrote:
But why make misleading syntax? More of a question for John: why write
|load(bar.js)| there, looking for all the world like a function call
evaluated in order at runtime,
On Wed, Mar 21, 2012 at 11:33 PM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
On 22 March 2012 16:30, David Herman dher...@mozilla.com wrote:
On Mar 22, 2012, at 4:46 AM, Andreas Rossberg wrote:
Nice! One question: is there a reason why you not just define
Program ::= ModuleBody
?
No exports from a Program.
Except that the syntax currently includes that.
The bracket syntax is pretty confusing with object literal notation imo.
It shouldn't be too confusing, and the similarity is in fact intentional.
You should read import as destructuring (and export as the inverse
structuring, if you want).
I agree that this isn't really a question
Andreas Rossberg wrote:
I still wonder why you think it is so confusing to use the equality
sign for module bindings. It is overloaded to mean define as and
assign in almost all language that use it for the latter, and for
different semantic categories, too. I never witnessed anybody being
David Herman wrote:
The 'at' might be appropriate but it just looks like an unfinished
thought: the module foo at 'foo.js' ...what? Both the import-as and
module-= forms state what the declaration is doing. The former
declares it is importing the module; the latter declares it is
John J Barton wrote:
I guess you mean: a special form evaluated before the outer function
runs? Surely this form is not off-line.
No, before anything in the containing Program (up to the script
container) runs. Modules are prefetched, not loaded by a nested event
loop that violates
On Mar 22, 2012, at 9:12 AM, Luke Hoban wrote:
The bracket syntax is pretty confusing with object literal notation imo.
It shouldn't be too confusing, and the similarity is in fact intentional.
You should read import as destructuring (and export as the inverse
structuring, if you want).
Luke Hoban wrote:
At least half the times I've shown object destructuring or module import renaming syntax
I've gotten don't you have that backwards? remarks. I can't say I have a
better recommendation for the general object destructuring syntax, but I expect this to
be a point of
Allen Wirfs-Brock wrote:
I also find myself getting it backwards, but it helps me to remember that for
destructing assignment the target needs to be an arbitrary LHS which won't
really fit well to the right of the :
You mean left, not right. ;-)
/be
On Mar 22, 2012, at 10:56 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I also find myself getting it backwards, but it helps me to remember that
for destructing assignment the target needs to be an arbitrary LHS which
won't really fit well to the right of the :
You mean left, not
On Thu, Mar 22, 2012 at 10:32 AM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
I guess you mean: a special form evaluated before the outer function
runs? Surely this form is not off-line.
No, before anything in the containing Program (up to the script container)
runs.
John J Barton wrote:
Second, we need a solution for asynchronous loading with run-time
selection. We use it now and as we move to much better network layers
we will use it a lot more.
Of course. This is what the
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders API is all
about.
On Thu, Mar 22, 2012 at 1:54 PM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
Second, we need a solution for asynchronous loading with run-time
selection. We use it now and as we move to much better network layers
we will use it a lot more.
Of course. This is what the
On Thu, Mar 22, 2012 at 5:11 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
The module solution posted seems to have a top-notch solution for the
static case but the dynamic case is buried in the loader.
I don't really understand what you mean by buried in the loader.
Here's the dynamic
Btw, another question that has bugged me lately: with 1JS, what
happens when I do a sloppy-mode direct eval on a program string
containing a module declaration? In global scope? In local scope?
It's a good question, and one I've thought about some. This could
use some whiteboard time -- let's
On Thu, Mar 22, 2012 at 3:06 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Thu, Mar 22, 2012 at 5:11 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
The module solution posted seems to have a top-notch solution for the
static case but the dynamic case is buried in the loader.
I
On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eich bren...@mozilla.org wrote:
John J Barton wrote:
If I go back to my previous question, can we understand what should happen
here?
if (version === 1)
import y from 'lib1.js';
else
import y from 'lib2.js';
Again, no.
No, we can't understand
John J Barton wrote:
On Thu, Mar 22, 2012 at 4:54 PM, Brendan Eichbren...@mozilla.org wrote:
John J Barton wrote:
If I go back to my previous question, can we understand what should happen
here?
if (version === 1)
import y from 'lib1.js';
else
import y from 'lib2.js';
Again, no.
No,
H'lo,
Thanks to some a-maz-ing [1] work by Andreas Rossberg (I'll spare the gory
algorithmic details), the linking process no longer needs the syntactic
distinction that static module bindings are only created via the `module`
(contextual) keyword. This frees us up to simplify the syntax,
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of David Herman
Sent: Wednesday, March 21, 2012 3:29 PM
To: es-discuss discussion
Subject: simpler, sweeter syntax for modules
H'lo,
Thanks to some a-maz-ing [1] work by Andreas Rossberg (I'll
I like it, more in line with AMDs and Node.js modules.
Honest question: Are nested modules really needed?
On Mar 21, 2012, at 23:28 , David Herman wrote:
H'lo,
Thanks to some a-maz-ing [1] work by Andreas Rossberg (I'll spare the gory
algorithmic details), the linking process no longer
: simpler, sweeter syntax for modules
H'lo,
Thanks to some a-maz-ing [1] work by Andreas Rossberg (I'll spare the gory
algorithmic details), the linking process no longer needs the syntactic
distinction that static module bindings are only created via the `module`
(contextual) keyword
On Wed, Mar 21, 2012 at 4:05 PM, Axel Rauschmayer a...@rauschma.de wrote:
Honest question: Are nested modules really needed?
There is a chance that they would be useful for bundling. Modules
can’t be concatenated.
Kris Kowal
___
es-discuss mailing
On Mar 21, 2012, at 3:44 PM, Luke Hoban wrote:
Great to see the updates. A couple of questions:
import foo.js as Foo;
import foo from foo.js;
These two forms look rather confusingly similar given how different they are,
and the inversion of order of where the filename lives doesn't
This looks really nice!
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mar 21, 2012, at 4:25 PM, Kris Kowal wrote:
On Wed, Mar 21, 2012 at 4:05 PM, Axel Rauschmayer a...@rauschma.de wrote:
Honest question: Are nested modules really needed?
There is a chance that they would be useful for bundling. Modules
can’t be concatenated.
Yeah, I believe that's the
I like variant B, because it follows the rules:
- module = define a module
- import = extract something out of a module
But I would use a keyword instead of = (due to the reason that you
mentioned). Compare:
module Bar = bar.js;
module Bar is bar.js;
module Bar from bar.js;
David Herman wrote:
On Mar 21, 2012, at 3:44 PM, Luke Hoban wrote:
Great to see the updates. A couple of questions:
import foo.js as Foo;
import foo from foo.js;
[snip]
Andreas also didn't like the inversion of order. I came to this because earlier
versions of the syntax were
David Herman wrote:
On Mar 21, 2012, at 3:44 PM, Luke Hoban wrote:
Great to see the updates. A couple of questions:
import foo.js as Foo;
import foo from foo.js;
[snip]
Andreas also didn't like the inversion of order. I came to this because earlier versions of the syntax were
51 matches
Mail list logo
