ted parties, its a question of
programming in the large vs small. In a sufficiently large system, even
trusted parties are equipped with sufficiently advanced cluelessness about
other modules invariants that the line between malice and ignorance is
blurred. Rather than create two different module
Jasvir Nagra
http://www.cs.auckland.ac.nz/~jas
On Mon, May 24, 2010 at 6:21 AM, Mike Wilson wrote:
> Jasvir Nagra wrote:
>
> According to your proposal, one.js is doing in essence a text inclusion
> of the contents of two.js and as a result is susceptible to the
> problems unhygienic macro ex
> zero.js:
> module One = load 'one.js';
> module Drawing = load 'gun.js';
> module JQ = load 'jquery.js';
>
> one.js:
> import JQ;
> module Two = load 'two.js';
>
> two.js:
> import JQ;
> import Drawing;
> Drawing.draw();
>
> The module of concern to us is one.js. According to your proposal, o
Jasvir Nagra wrote:
According to your proposal, one.js is doing in essence a text inclusion of the
contents of two.js and as a result is susceptible to the problems unhygienic
macro expansion suffers.
I have been thinking about similar concerns, but, as the proposal mentions
separate compil
module B = load 'http://.../b.js'; // module B gets JQ and Drawing but
> it
> > can't utter something to get it the shared Fribble
> > }
>
> Two things about this. This is the recommended solution to this
> problem in our proposal, since it eliminates accid
2010/5/20 ๏̯͡๏ Jasvir Nagra :
> The other is to limit the scope from which the imported modules imports get
> selected to the current scope:
> module Fribble {}
> module Foo {
> module JQ = load 'http://';
> module Drawing = load 'http://.../gun.js';
> module A = load 'http://.../a.js';
On Thu, May 20, 2010 at 3:47 PM, Mike Wilson wrote:
> Thanks for the detailed explanations, David. Here's a few follow-
> up questions (with "done" questions snipped out):
Thanks for all your detailed feedback!
> David Herman wrote:
>> > | This allows cyclic dependencies between any two modules
Thanks for the detailed explanations, David. Here's a few follow-
up questions (with "done" questions snipped out):
David Herman wrote:
> > | This allows cyclic dependencies between any two modules
> > | in a single scope
> >
> > 1) Is this to say that cycles are allowed, or not allowed, in
>
> Heh-- excuse my bogus BNF! That's just a made-up extension that allows 1 or
> more instances of MRL, separated by the ',' token. Spelled out:
>
>MRL+(',') ::= MRL
> | MRL+(',') ',' MRL
PS If this is still unclear, just replace MRL+(',') with MRLList, and add the
production:
Hi Mike, sorry I overlooked this message.
> | This allows cyclic dependencies between any two modules
> | in a single scope
>
> 1) Is this to say that cycles are allowed, or not allowed, in
> other scenarios? (f ex remote or filesystem-loaded modules)
It's an automatic consequence of lexical
> So both the moda.js and modb.js source files can contain (for example):
> ModUtils.myfunc();
>
> And can import the exports of ModUtils:
> import ModUtils.myfunc;
> myfunc();
Yes.
> Is it correct that a module declaration within a script tag only has
> scope within that script tag?
No, each s
On Wed, May 19, 2010 at 3:04 PM, David Herman wrote:
> If they want to share a utility module, you pull it out into a place that's
> in scope for both ModA and ModB:
>
>
> module ModUtils = load "http://acme.com/modutils.js";;
>
> That's surprising. Within a moduleloader I would have thought that
> same url meant the same static module. Across moduleloaders maybe not.
The problem is defining "same url." One option is that "same" means "identical
string" but then when http://example.com/foo.html says:
module A =
On Wed, May 19, 2010 at 2:59 AM, Kevin Curtis wrote:
>
> For the following scenario:
>
> module ModA = "http://acme.com/moda.js";;
> module ModB = "http://acme.com/modb.js";;
> ... source
On Mon, May 17, 2010 at 4:07 PM, David Herman wrote:
> [snip] For example, consider:
>
> module M = load "http://example.com/foo.js";;
> module N = load "http://example.com/foo.js";;
>
> These two modules are loaded from the exact same MRL, but the module system
> treats them as two comple
> Oh, but you probably meant that the module table form, besides being sugar,
> is written in a restricted language that cannot have effects other than to
> create module bindings -- cannot do document.write or
> document.createElementNS("script") or whatever. In that case we'd want
> type="har
On May 17, 2010, at 12:12 PM, David Herman wrote:
Coalescing requests (for some value of request) could be pushed
down a layer, not specified as part of the ECMA-262 language. This
serves the decoupling requirement. Is it enough? A while ago Allen
wrote about separating "configuration manag
> Coalescing requests (for some value of request) could be pushed down a layer,
> not specified as part of the ECMA-262 language. This serves the decoupling
> requirement. Is it enough? A while ago Allen wrote about separating
> "configuration management":
>
> https://mail.mozilla.org/pipermail
> 1. Is it possible to import parts of a module to avoid potentially large
> network payloads?
Not parts of a module, no. (The semantics of this would be incredibly hairy and
hard to define.) But you can dynamically load modules, so you can write code
that decides dynamically when to load modul
mentation of simple modules, and with some thought
experiments.
/be
thanks
Kam
From: David Herman
To: Mike Shaver
Cc: Kam Kasravi ; Brendan Eich >; P T Withington ; es-discuss Steen >
Sent: Mon, May 17, 2010 8:22:52 AM
Subject: Re: modules proposal
> For this, I would rather let the e
ere syntax that would allow the server to group or concatenate delivery
of multiple modules within one request?
thanks
Kam
From: David Herman
To: Mike Shaver
Cc: Kam Kasravi ; Brendan Eich ; P T
Withington ; es-discuss Steen
Sent: Mon, May 17, 2010 8:22:52 AM
Subject: Re: modules propo
> For this, I would rather let the exporter define named export lists,
> so that there's better future proofing. I would hate to be the person
> adding something to the SVG module knowing that there were a bunch of
> regexps floating around the web that might cause me to clobber
> something unexpe
> module JSON = load 'http://json.org/modules/json2.js';
>
> 1) Does - or must - the file json2.js contain only a single top level
> module declaration:
>
> module JSON {
> ...source...
> }
No. The file json2.js contains the *body* of the JSON module. It can declare as
many modules, variables
> No worries - the examples page is very useful.
>
> In your original email:
> module Even = "http://example.com/even.js";;
> module Odd = "http://example.com/odd.js";;
>
> Is the load keyword missing:
> module Even = load "http://example.com/even.js";;
Yes, sorry for another inconsistency there
On Mon, May 17, 2010 at 12:37 AM, Kam Kasravi wrote:
> [kam] An example might be something like SVG.*Filter* where the importer was
> interested in retrieving only filter related features within a SVG module.
For this, I would rather let the exporter define named export lists,
so that there's bet
David Herman wrote:
> Hello!
>
> I've updated the strawman proposals for static modules and
> dynamic module loaders and would love to get feedback from
> the es-discuss community.
>
> * Static modules:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
>
http://wiki.ecmasc
A couple more questions:
In strawman:simple_modules_examples - Remote modules on the web (1):
// loading from a URL
module JSON = load 'http://json.org/modules/json2.js';
alert(JSON.stringify({'hi': 'world'}));
1) Does - or must -
No worries - the examples page is very useful.
In your original email:
module Even = "http://example.com/even.js";;
module Odd = "http://example.com/odd.js";;
Is the load keyword missing:
module Even = load "http://example.com/even.js";;
--
___
es-di
Yeah, sorry, that example went through several iterations as the modules
proposal evolved, and now it's kind of muddled. I'll update it tomorrow.
Since the reference to the module is used in an expression, it could
technically be thought of as reflecting the module as an object and p
On Mon, May 17, 2010 at 6:02 AM, David Herman wrote:
> This was the point I was explaining here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2010-May/011162.html
>
> Modules are static entities, whose structure is known at compile-time. The
> "module" form creates these static bindings.
This was the point I was explaining here:
https://mail.mozilla.org/pipermail/es-discuss/2010-May/011162.html
Modules are static entities, whose structure is known at compile-time. The
"module" form creates these static bindings. But they can be reflected as
first-class values. (Similar to e
Thanks Brendan, David.
A few comments below.
From: Brendan Eich
To: David Herman
Cc: Kam Kasravi ; P T Withington ;
es-discuss Steen
Sent: Sun, May 16, 2010 8:00:35 PM
Subject: Re: modules proposal
On May 16, 2010, at 7:18 PM, David Herman wrote
On Mon, May 17, 2010 at 3:27 AM, David Herman wrote:
> This makes it very convenient to reflect them as first-class values:
>
> var x = Math;
> alert(x["sum"]); // function(x,y) { ... }
> alert(x["thisIsNotDefined"]); // undefined
>
Whats the difference between:
var x = Math; // or: cons
On May 16, 2010, at 7:18 PM, David Herman wrote:
RegExp literal expressions evaluate to mutable object values, per
ES5 and reality (ES3 got this wrong, making an object per literal
lexeme -- not per evaluated expression).
Yes, but there's no reason to assume a RegExp token would be a
RegE
> Stupid question - is the following form of (Python-ish) import
> possible (from the grammar it doesn't look like it):
>
> [snip]
>
> Or is it the case that with a module {...} declaration the module is
> immediately accessible in the scope it was declared in - and no import
> required if module
> RegExp literal expressions evaluate to mutable object values, per ES5 and
> reality (ES3 got this wrong, making an object per literal lexeme -- not per
> evaluated expression).
Yes, but there's no reason to assume a RegExp token would be a RegExp literal
expression.
> Modules are static. Do
Stupid question - is the following form of (Python-ish) import
possible (from the grammar it doesn't look like it):
import Math; // Math module declared above
alert("2π = " + Math.sum(pi, pi));
Or is it the case that with a module {...} declaration the module is
immediately accessible in the s
On May 16, 2010, at 1:36 PM, David Herman wrote:
Along these lines of imports, a regex would allow partial imports.
I'm a little hesitant on this idea; on the one hand it's nice that
we already have literal support for regexps, so it's not a huge
conceptual or syntactic overhead.
RegExp
> See, even after I knew the rules it was too confusing. Can we go back
> to using "as"?
>
> import draw as drawGun from Cowboy;
This is an incomplete suggestion. What do you want the full syntax to be for
multiple imports? Force the user to write a separate one on each line? Bracket
them? Comm
> Along these lines of imports, a regex would allow partial imports.
I'm a little hesitant on this idea; on the one hand it's nice that we already
have literal support for regexps, so it's not a huge conceptual or syntactic
overhead. OTOH, like Brendan suggested for "export all except" it smacks
> This is a minor point, but rather than all, we'd use * instead, to mirror
> import M.* or M.{*} or import * from M; whatever it ends up being.
Agreed.
As for the meaning: from my experience with PLT Scheme it works well for
"export *;" to export everything that's defined in the module, but no
t; On May 16, 2010, at 11:15 AM, Charles Jolley wrote:
>
>> I am unclear from this proposal. What would happen if I declared the same
>> module twice? Would it reopen the module and add the extra declarations?
>
> The simple modules proposal makes it an error to export twice.
On May 16, 2010, at 11:15 AM, Charles Jolley wrote:
I am unclear from this proposal. What would happen if I declared
the same module twice? Would it reopen the module and add the extra
declarations?
The simple modules proposal makes it an error to export twice. This is
a bit implicit
On 16.05.2010 22:11, Brendan Eich wrote:
On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
On 15.05.2010 19:22, Brendan Eich wrote:
On May 15, 2010, at 7:53 AM, David Herman wrote:
I wonder if you considered having an export list, rather than
tagging the individual exports? I think th
I am unclear from this proposal. What would happen if I declared the
same module twice? Would it reopen the module and add the extra
declarations?
-Charles
On May 16, 2010, at 11:11 AM, Brendan Eich wrote:
On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
On 15.05.2010 19:22, B
On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
On 15.05.2010 19:22, Brendan Eich wrote:
On May 15, 2010, at 7:53 AM, David Herman wrote:
I wonder if you considered having an export list, rather than
tagging the individual exports? I think that makes it easier to
see/document the
On 15.05.2010 19:22, Brendan Eich wrote:
On May 15, 2010, at 7:53 AM, David Herman wrote:
I wonder if you considered having an export list, rather than
tagging the individual exports? I think that makes it easier to
see/document the public API of a module. You could at the same time
allow r
On Sat, May 15, 2010 at 16:47, Brendan Eich wrote:
> The exported name is draw, the rename target is drawShape, so you want
>
> import {draw: drawShape} from Geometry.
>
> Compare destructuring:
>
> let {draw: drawGun} = cowboy;
> drawGun();
See, even after I knew the rules it was too confusing.
On May 15, 2010, at 2:49 PM, Erik Arvidsson wrote:
On Sat, May 15, 2010 at 09:13, P T Withington wrote:
Ah, destructing `.`, I missed that. Perhaps I would have gotten it
with a closer parallel like
let { draw: d } = import M;
I don't like this since it makes it look like (import M) is
I'm happy this is finally receiving some comments. This is at the top
of my wish list for ESH.
I do agree that the current syntax seemed a bit off at first glance.
Now that Brendan pointed out that it is the destructuring pattern it
seems slightly better but still not perfect.
I also agree with o
On 16.05.2010 1:33, Erik Arvidsson wrote:
On Sat, May 15, 2010 at 05:20, Dmitry A. Soshnikov
wrote:
How about a small syntactic sugar for useful and widespread construction:
x = x || 10
Off topic but see
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
On Sat, May 15, 2010 at 05:20, Dmitry A. Soshnikov
wrote:
> How about a small syntactic sugar for useful and widespread construction:
>
> x = x || 10
Off topic but see
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
--
erik
___
Along these lines of imports, a regex would allow partial imports.
On May 15, 2010, at 4:53 AM, P T Withington wrote:
> On 2010-05-13, at 19:41, David Herman wrote:
>
>> I've updated the strawman proposals for static modules and dynamic module
>> loaders and would love to get feedback from t
On 2010-05-15, at 11:22, Brendan Eich wrote:
>> On May 15, 2010, at 7:53 AM, David Herman wrote:
[...]
>>> FWIW, the rename on import looked "backwards" to me at first glance, but I
>>> think I can learn.
>>
>> Yeah, I'm not thrilled about how hard it is to remember which way it goes. I
>> mean
On May 15, 2010, at 7:53 AM, David Herman wrote:
I wonder if you considered having an export list, rather than
tagging the individual exports? I think that makes it easier to
see/document the public API of a module. You could at the same
time allow renaming on export.
Yes, this is a goo
> Thought looking at the syntax section it seems that `import Math;` isn't
> valid and instead you do it as `module Math = Math`. Why not use import here
> as well? My first instinct here is `module` is for defining a module and
> `import` is importing it - instead `module` serves a dual functio
> I wonder if you considered having an export list, rather than tagging the
> individual exports? I think that makes it easier to see/document the public
> API of a module. You could at the same time allow renaming on export.
Yes, this is a good point. We chose inline-export for convenience, b
> How about a small syntactic sugar for useful and widespread construction:
>
> x = x || 10
>
> to remove this repetition from the right side:
>
> x ||= 10.
>
> module JSON ||= load(...);
I do not mean to hijack this thread about what seems a very good modules
pro
On 15.05.2010 15:53, P T Withington wrote:
On 2010-05-13, at 19:41, David Herman wrote:
I've updated the strawman proposals for static modules and dynamic module
loaders and would love to get feedback from the es-discuss community.
* Static modules:
http://wiki.ecmascript.org/doku.ph
On 15 May 2010, at 12:53, P T Withington wrote:
> On 2010-05-13, at 19:41, David Herman wrote:
>
>> I've updated the strawman proposals for static modules and dynamic module
>> loaders and would love to get feedback from the es-discuss community.
>>
>> * Static modules:
>>
>> http://wiki.ecma
On 2010-05-13, at 19:41, David Herman wrote:
> I've updated the strawman proposals for static modules and dynamic module
> loaders and would love to get feedback from the es-discuss community.
>
> * Static modules:
>
>http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
>http:
On May 13, 2010, at 11:39 PM, Erik Arvidsson wrote:
> On Thu, May 13, 2010 at 16:41, David Herman wrote:
>>http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
>>http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules_examples
>
> This looks really good. I hope we can m
On Thu, May 13, 2010 at 16:41, David Herman wrote:
> http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
> http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules_examples
This looks really good. I hope we can move this from strawman into
proposals at the next face to face
Hello!
I've updated the strawman proposals for static modules and dynamic module
loaders and would love to get feedback from the es-discuss community.
* Static modules:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
http://wiki.ecmascript.org/doku.php?id=strawman:simple_
On Sun, Feb 8, 2009 at 4:50 PM, Peter Michaux wrote:
> On Sun, Feb 8, 2009 at 1:06 PM, Dave Herman wrote:
>
>> I like many aspects of Ihab and Kris's proposal, but not all.
>
> For example which parts do you like or dislike?
Speaking for myself, one problem I see is that the proposal leaves
inte
I'm afraid I haven't had enough time to think all of this through yet.
I feel that there are a few areas where we can separate some concerns
and produce more orthogonal proposals. I'll be sure to post as soon as
I have my thoughts together more.
I understand you would like to move ServerJS
On Sun, Feb 8, 2009 at 1:06 PM, Dave Herman wrote:
> I like many aspects of Ihab and Kris's proposal, but not all.
For example which parts do you like or dislike? The reason I ask, it
would be great if the ServerJS project could use a reasonably liked
subset of the proposal. The ServerJS discuss
[I'm having mail server issues, so I apologize if this message doesn't
thread appropriately.]
Peter Michaux wrote:
The ServerJS project is a bright light in the server-side JavaScript
world. Knowing sooner than later if this module idea is appealing to
the ECMAScript group would be useful infor
On Thu, Jan 22, 2009 at 10:00 PM, wrote:
> Hi folks,
>
> Kris Kowal and I plan to present a proposal for ES-Harmony modules in
> the upcoming Mountain View meeting. In the interests of giving
> everyone a chance to read through our ideas ahead of time, we are
> sharing a draft of our document, wh
Hi folks,
Kris Kowal and I plan to present a proposal for ES-Harmony modules in
the upcoming Mountain View meeting. In the interests of giving
everyone a chance to read through our ideas ahead of time, we are
sharing a draft of our document, which is a work in progress:
http://docs.google.com/D
70 matches
Mail list logo
