No subject
Thu Feb 11 18:09:36 PST 2010
<br>
=C2=A0| // compiler/Lexer.js<br>
=C2=A0| module Lexer { ... }<br>
=C2=A0| ...<br>
=C2=A0| // Main.js<br>
=C2=A0| import compiler.Lexer.*;<br>
<br>
2) Am I understanding this correctly as the module loader<br>
fetching and registering Lexer.js "on demand" if not already<br>
present in its registry mapping?<br>
<br>
3) Is Lexer.js required to contain exactly one module<br>
declaration that must match the filename, or otherwise an<br>
exception is thrown?<br>
<br>
4) Would this on demand loading functionality be present<br>
also on the web platform?<br>
<br>
5) If so, would then the uses in main1 and main2 be equivalent<br>
wrt binding MyLib names in the example below?<br>
<br>
=C2=A0// lib/MyLib.js<br>
=C2=A0module MyLib { export doStuff() ... }<br>
<br>
=C2=A0// main1.js<br>
=C2=A0import lib.MyLib.*;<br>
=C2=A0doStuff();<br>
<br>
=C2=A0// main2.js<br>
=C2=A0module wrapper =3D load "lib/MyLib.js";<br>
=C2=A0import wrapper.MyLib.*;<br>
=C2=A0doStuff();<br>
<br>
"Importing" module level<br>
------------------------<br>
<br>
6) If I want to change the previous example to instead expose<br>
MyLib's names inside a MyLib module name, would I then do<br>
the following? :<br>
<br>
=C2=A0// main1.js<br>
=C2=A0module MyLib =3D lib.MyLib;<br>
=C2=A0MyLib.doStuff();<br>
<br>
=C2=A0// main2.js<br>
=C2=A0module wrapper =3D load "lib/MyLib.js";<br>
=C2=A0module MyLib =3D wrapper.MyLib;<br>
=C2=A0MyLib.doStuff();<br>
<br>
Wrapper module on loaded scripts<br>
--------------------------------<br>
<br>
In the "Remote modules on the web (1)" example we have:<br>
7) Am I understanding correctly that this is pointing to a<br>
plain script (without module decls) which is wrapped inside<br>
the JSON module we specify?<br>
<br>
8) Imagine a json2mod.js with an embedded:<br>
<br>
=C2=A0module JSON { ... }<br>
<br>
which would result in:<br>
<br>
=C2=A0module JSON =3D load '<a href=3D"http://json.org/modules/json2mo=
d.js" target=3D"_blank">http://json.org/modules/json2mod.js</a>';<br>
=C2=A0alert(JSON.JSON.stringify({'hi': 'world'}));<br>
<br>
Is this assumption correct?<br>
<br>
9) If so, what syntax could be used to avoid the extra wrapper<br>
module at load? Could there f ex be a standalone load syntax<br>
that evaluates straight into the current scope:<br>
<br>
=C2=A0load '<a href=3D"http://json.org/modules/json2mod.js" target=3D"=
_blank">http://json.org/modules/json2mod.js</a>';<br>
(disclaimer: haven't thought much about implications of this)<br>
<br>
MRLs<br>
----<br>
<br>
In the "Static module detection" example we have:<br>
<br>
=C2=A0| // compiler tries each in order<br>
=C2=A0| module JSON =3D load ('JSON' || '<a href=3D"http://jso=
n.org/modules/json2.js'" target=3D"_blank">http://json.org/modules/json=
2.js'</a>);<br>
<br>
10) Does this syntax mix module identifiers and MRLs? (the<br>
'JSON' item looks very much like a pre-registered module in<br>
the module registry?)<br>
<br>
11) [Excuse my poor BNF] What is the +(',') for in:<br>
<br>
=C2=A0| ModuleDeclaration ::=3D 'module' Identifier '=3D' =
'load' MRL+(',') ';'<br>
<br>
Best regards<br>
<font color=3D"#888888">Mike Wilson<br>
</font><div><div></div></div><br>----------<br><span><font color=3D"#888">F=
rom: <b>Mike Shaver</b> <span dir=3D"ltr"><<a href=3D"mailto:mike.shaver=
@gmail.com" target=3D"_blank">mike.shaver at gmail.com</a>></span><br>
Date: Mon, May 17, 2010 at 5:59 AM<br>To: Kam Kasravi <<a href=3D"mailto=
:kamkasravi at yahoo.com" target=3D"_blank">kamkasravi at yahoo.com</a>><br>Cc=
: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D"=
_blank">es-discuss at mozilla.org</a>>, Brendan Eich <<a href=3D"mailto:=
brendan at mozilla.com" target=3D"_blank">brendan at mozilla.com</a>>, P T Wit=
hington <<a href=3D"mailto:ptw at pobox.com" target=3D"_blank">ptw at pobox.co=
m</a>><br>
</font><br></span><br>For this, I would rather let the exporter define name=
d export lists,<br>
so that there's better future proofing. =C2=A0I would hate to be the pe=
rson<br>
adding something to the SVG module knowing that there were a bunch of<br>
regexps floating around the web that might cause me to clobber<br>
something unexpected.<br>
<br>
Given Foo.* meaning what it will, I suspect we would see people<br>
writing exactly what you did above, and being surprised that they<br>
didn't get what they wanted: they want globs, not regexps, for that.<br=
>
("*Filter*" isn't even a legal regexp, so they'd get a co=
mpilation<br>
error, but when you have to write SVG..*Filter.*, I think it gets to<br>
be pretty unwieldy.)<br>
<font color=3D"#888888"><br>
Mike<br>
</font><div><div></div></div><br>----------<br><span><font color=3D"#888">F=
rom: <b>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mo=
zilla.com" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Mon, May 17, 2010 at 8:07 AM<br>To: Kevin Curtis <<a href=3D"mailt=
o:kevinc1846 at gmail.com" target=3D"_blank">kevinc1846 at gmail.com</a>><br>C=
c: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D=
"_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>Yes, sorry for another inconsistency there. FWIW, I&#=
39;m not married to that particular syntax. I put the "load" keyw=
ord into the proposal just to emphasize that these strings correspond to a =
compile-time action (loading the bits). For example, consider:<br>
<br>
=C2=A0 =C2=A0module M =3D load "<a href=3D"http://example.com/foo.js"=
target=3D"_blank">http://example.com/foo.js</a>";<br>
=C2=A0 =C2=A0module N =3D load "<a href=3D"http://example.com/foo.js"=
target=3D"_blank">http://example.com/foo.js</a>";<br>
<br>
These two modules are loaded from the exact same MRL, but the module system=
treats them as two completely separate, independent modules. (Even custom =
module loaders shouldn't be able to change this fact, since all they ca=
n do is deliver the bits of a module resource.)<br>
<br>
The reason for this is that on the web, there's just no way to know tha=
t two URL's point to the "same" resource-- fetching the bit-f=
or-bit-same URL even microseconds apart can result in completely different =
data, since web servers are free to deliver whatever they want. So the modu=
le loading semantics is resolutely non-clever about interpreting MRL's.=
<br>
<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.c=
om" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Mon, May 17, 2010 at 8:19 AM<br>To: Kevin Curtis <<a href=3D"mailt=
o:kevinc1846 at gmail.com" target=3D"_blank">kevinc1846 at gmail.com</a>><br>C=
c: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D=
"_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>No. The file json2.js contains the *body* of the JSON=
module. It can declare as many modules, variables, and functions as it lik=
es.<br>
<br>
This is less brittle (doesn't require careful coordination between clie=
nt and library), and crucially it gives the client control over module nami=
ng, so that if two vendors produce a module called SuperWidgets, then the c=
lient can do:<br>
<br>
=C2=A0 =C2=A0module Acme =3D "<a href=3D"http://acme.com/superwidgets=
.js" target=3D"_blank">http://acme.com/superwidgets.js</a>";<br>
=C2=A0 =C2=A0module Haxx0rz =3D "<a href=3D"http://haxx0rz.com/superw=
idgets.js" target=3D"_blank">http://haxx0rz.com/superwidgets.js</a>";<=
br>
<br>
=C2=A0 =C2=A0import Acme.SuperWidgets.foo;<br>
=C2=A0 =C2=A0import Haxx0rz.SuperWidgets.bar;<br>
<br>
=C2=A0 =C2=A0// ...<br>
<br>
It's also more convenient for library writers, who don't have to wr=
ap their entire top-level source file with an annoying boilerplate module d=
eclaration.<br>
That's mostly true, except for the fact that the <script> tag doe=
sn't wrap the contents in a module. Thanks for bringing this up, it'=
;s a good point. It might suggest an extra HTML attribute to go that last s=
tep:<br>
<br>
=C2=A0 =C2=A0<script type=3D"harmony" module=3D"JSON&quo=
t; src=3D"<a href=3D"http://json.org/modules/json2.js" target=3D"_blan=
k">http://json.org/modules/json2.js</a>"></script><br>
<br>
(Which is of course, out of our jurisdiction to specify here, but coordinat=
ion with other web standards will at some point be necessary, and it's =
helpful to have at least plausible recommendations.)<br>
<br>
However, I believe it should also still be possible for browsers to prefetc=
h and parallelize the compilation of source from within module declarations=
with MRL's, too. This is something we need to experiment with in real =
implementations, though.<br>
<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.c=
om" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Mon, May 17, 2010 at 8:22 AM<br>To: Mike Shaver <<a href=3D"mailto=
:mike.shaver at gmail.com" target=3D"_blank">mike.shaver at gmail.com</a>><br>=
Cc: Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_blan=
k">brendan at mozilla.com</a>>, P T Withington <<a href=3D"mailto:ptw at po=
box.com" target=3D"_blank">ptw at pobox.com</a>>, es-discuss Steen <<a h=
ref=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.=
org</a>><br>
</font><br></span><br>This gets to my main issue with regexps (aside from t=
he YAGNI aspect) -- it puts too much significance into variable names, and =
becomes a refactoring hazard.<br>
FWIW, you could distinguish this with the regexp syntax, for example:<br>
<br>
=C2=A0 =C2=A0import SVG./.*Filter.*/;<br>
=C2=A0 =C2=A0import /.*Filter.*/ from SVG;<br>
<br>
But ... um, well, yeah.<br>
<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>Kam Kasravi</b> <span dir=3D"ltr"><<a href=3D"mailto:kamkasravi at yahoo.c=
om" target=3D"_blank">kamkasravi at yahoo.com</a>></span><br>
Date: Mon, May 17, 2010 at 10:30 AM<br>To: David Herman <<a href=3D"mail=
to:dherman at mozilla.com" target=3D"_blank">dherman at mozilla.com</a>>, Mike=
Shaver <<a href=3D"mailto:mike.shaver at gmail.com" target=3D"_blank">mike=
.shaver at gmail.com</a>><br>
Cc: Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_blan=
k">brendan at mozilla.com</a>>, P T Withington <<a href=3D"mailto:ptw at po=
box.com" target=3D"_blank">ptw at pobox.com</a>>, es-discuss Steen <<a h=
ref=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.=
org</a>><br>
</font><br></span><br><div><div style=3D"font-family:'times new roman&#=
39;, 'new york', times, serif;font-size:12pt"><div>Thanks Mike, Dav=
id.</div><div><br></div><div>I agree with the conclusion that regex probabl=
y isn't the best way to tackle these problems.</div>
<div>I'll summarize the use cases since it may apply in later discussio=
ns...</div><div><br></div><div>1. Is it possible to import parts of a modul=
e to avoid potentially large network payloads?</div><div>2. Is there syntax=
that would allow the server to group or concatenate delivery of multiple m=
odules within=C2=A0one request?</div>
<div><br></div><div><br></div><div>thanks</div><div>Kam</div><div><br></div=
><div><br></div><div><br></div><div><br></div><div></div><div style=3D"font=
-family:times new roman, new york, times, serif;font-size:12pt"><div style=
=3D"font-family:arial, helvetica, sans-serif;font-size:13px">
<font size=3D"2" face=3D"Tahoma"><b><span style=3D"font-weight:bold">From:<=
/span></b> David Herman <<a href=3D"mailto:dherman at mozilla.com" target=
=3D"_blank">dherman at mozilla.com</a>><br><b><span style=3D"font-weight:bo=
ld">To:</span></b> Mike Shaver <<a href=3D"mailto:mike.shaver at gmail.com"=
target=3D"_blank">mike.shaver at gmail.com</a>><br>
<b><span style=3D"font-weight:bold">Cc:</span></b> Kam Kasravi <<a href=
=3D"mailto:kamkasravi at yahoo.com" target=3D"_blank">kamkasravi at yahoo.com</a>=
>; Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_bl=
ank">brendan at mozilla.com</a>>; P T Withington <<a href=3D"mailto:ptw@=
pobox.com" target=3D"_blank">ptw at pobox.com</a>>; es-discuss Steen <<a=
href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozill=
a.org</a>><br>
<b><span style=3D"font-weight:bold">Sent:</span></b> Mon, May 17, 2010 8:22=
:52 AM<br><b><span style=3D"font-weight:bold">Subject:</span></b> Re: modul=
es proposal<br></font></div></div><div></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
<a href=3D"https://mail.mozilla.org/listinfo/es-discuss" target=3D"_blank">=
https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br><br>----------<br><span><font color=3D"#888">From: <b>Brendan Eich</b> =
<span dir=3D"ltr"><<a href=3D"mailto:brendan at mozilla.com" target=3D"_bla=
nk">brendan at mozilla.com</a>></span><br>Date: Mon, May 17, 2010 at 11:07 =
AM<br>
To: Kam Kasravi <<a href=3D"mailto:kamkasravi at yahoo.com" target=3D"_blan=
k">kamkasravi at yahoo.com</a>><br>Cc: es-discuss Steen <<a href=3D"mail=
to:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.org</a>>=
, P T Withington <<a href=3D"mailto:ptw at pobox.com" target=3D"_blank">ptw=
@pobox.com</a>><br>
</font><br></span><br><div style=3D"word-wrap:break-word"><div>It's mod=
ules all the way down. You only import what you specify from the module, bu=
t that doesn't affect downloading or indeed express the module dependen=
cy -- the dependency comes from module declarations creating bindings first=
, before any import from the module via its bound name.</div>
<div><br></div><div>Network payloads are induced by URL requests that miss =
the HTTP-rules-based cache. MRLs are not URLs, however, so there's an o=
pportunity here to coalesce load requests. See below.</div><div><br></div>
<div><br></div><div>This is a good question. The grouping of modules for do=
wnload should be decoupled from how one declares modules, to avoid mixing c=
oncerns and requiring refactoring or rewriting just on account of repackagi=
ng. Module declarations allow ahead of runtime loading, but they don't =
help coalesce requests.</div>
<div><br></div><div>Coalescing requests (for some value of request) could b=
e 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 a=
bout separating "configuration management":</div>
<div><br></div><div><a href=3D"https://mail.mozilla.org/pipermail/es-discus=
s/2010-January/010686.html" target=3D"_blank">https://mail.mozilla.org/pipe=
rmail/es-discuss/2010-January/010686.html</a></div><div><br></div><div>Part=
of this was about version selection, but part of it was about "assemb=
ly" structuring. It seems worth working through this, both with a real=
implementation of simple modules, and with some thought experiments.</div>
<div><br></div><font color=3D"#888888"><div>/be</div></font></div><br>_____=
__________________________________________<br>
es-discuss mailing list<br>
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
<a href=3D"https://mail.mozilla.org/listinfo/es-discuss" target=3D"_blank">=
https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br><br>----------<br><span><font color=3D"#888">From: <b>David Herman</b> =
<span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.com" target=3D"_bla=
nk">dherman at mozilla.com</a>></span><br>Date: Mon, May 17, 2010 at 12:07 =
PM<br>
To: Kam Kasravi <<a href=3D"mailto:kamkasravi at yahoo.com" target=3D"_blan=
k">kamkasravi at yahoo.com</a>><br>Cc: es-discuss Steen <<a href=3D"mail=
to:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.org</a>>=
, Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_blank"=
>brendan at mozilla.com</a>>, P T Withington <<a href=3D"mailto:ptw at pobo=
x.com" target=3D"_blank">ptw at pobox.com</a>><br>
</font><br></span><br><div style=3D"word-wrap:break-word"><div><div>Not par=
ts of a module, no. (The semantics of this would be incredibly hairy and ha=
rd to define.) But you can dynamically load modules, so you can write code =
that decides dynamically when to load modules.</div>
</div><div>Since modules can be nested, you can certainly put multiple modu=
les in a file; grouping them in a single module is nothing more than namesp=
ace management. So you can write:</div><div><br></div><div>=C2=A0=C2=A0 =C2=
=A0// file1.js</div>
<div>=C2=A0=C2=A0 =C2=A0module A { ... }</div><div>=C2=A0=C2=A0 =C2=A0modul=
e B { ... }</div><div>=C2=A0=C2=A0 =C2=A0...</div><div>=C2=A0=C2=A0 =C2=A0m=
odule Z { ... }</div><div><br></div><div>=C2=A0=C2=A0 =C2=A0// client.html<=
/div><div>=C2=A0=C2=A0 =C2=A0<script type=3D"harmony"></div=
><div>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0module MyLib =3D load "file1.js=
";</div>
<div>=C2=A0=C2=A0 =C2=A0</script></div><div><br></div><div>or with HT=
ML support, something like:</div><div><br></div><div>=C2=A0=C2=A0 =C2=A0// =
client.html</div><div>=C2=A0=C2=A0 =C2=A0<script type=3D"harmony&qu=
ot; module=3D"MyLib" src=3D"file1.js"></script>=
;</div>
<div><br></div><div>Dave</div><div><br></div></div><br>____________________=
___________________________<br>
es-discuss mailing list<br>
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
<a href=3D"https://mail.mozilla.org/listinfo/es-discuss" target=3D"_blank">=
https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br><br>----------<br><span><font color=3D"#888">From: <b>David Herman</b> =
<span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.com" target=3D"_bla=
nk">dherman at mozilla.com</a>></span><br>Date: Mon, May 17, 2010 at 12:12 =
PM<br>
To: Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_blan=
k">brendan at mozilla.com</a>><br>Cc: es-discuss Steen <<a href=3D"mailt=
o:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.org</a>>,=
P T Withington <<a href=3D"mailto:ptw at pobox.com" target=3D"_blank">ptw@=
pobox.com</a>><br>
</font><br></span><br><div style=3D"word-wrap:break-word"><div>Yes, certain=
ly. To some extent the module declaration syntax provides you enough to do =
this already:</div><div><br></div><div>=C2=A0=C2=A0 =C2=A0<!-- my config=
uration table --></div>
<div>=C2=A0=C2=A0 =C2=A0<script type=3D"harmony"></div><div=
>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0module M1 =3D "m1.js";</div><di=
v>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0module M2 =3D "m2.js";</div><d=
iv>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...</div><div>=C2=A0=C2=A0 =C2=A0</s=
cript></div><div><br></div><div>
But it might be nice to crystallize this in a restricted special form so br=
owsers can reliably prefetch:</div><div><br></div><div>=C2=A0=C2=A0 =C2=A0&=
lt;script type=3D"harmony"></div><div>=C2=A0=C2=A0 =C2=A0 =C2=
=A0 =C2=A0module table {</div><div>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0M1: "m1.js",</div>
<div>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M2: "m2.js",<=
/div><div>=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...</div><div>=
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0=C2=A0 =C2=A0</script=
></div><div><br></div><div>Dave</div><div><br></div></div><br>__________=
_____________________________________<br>
es-discuss mailing list<br>
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
<a href=3D"https://mail.mozilla.org/listinfo/es-discuss" target=3D"_blank">=
https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br><br>----------<br><span><font color=3D"#888">From: <b>Brendan Eich</b> =
<span dir=3D"ltr"><<a href=3D"mailto:brendan at mozilla.com" target=3D"_bla=
nk">brendan at mozilla.com</a>></span><br>Date: Mon, May 17, 2010 at 2:47 P=
M<br>
To: David Herman <<a href=3D"mailto:dherman at mozilla.com" target=3D"_blan=
k">dherman at mozilla.com</a>><br>Cc: es-discuss Steen <<a href=3D"mailt=
o:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.org</a>>,=
P T Withington <<a href=3D"mailto:ptw at pobox.com" target=3D"_blank">ptw@=
pobox.com</a>><br>
</font><br></span><br><div style=3D"word-wrap:break-word"><div><div><div></=
div></div>Either way allows prefetching once the type=3D"harmony"=
script content has been parsed. But the browser still would have to stall =
rendering while that "module table" script tag was being processe=
d, as far as I can tell. Any later scripts would block too, to avoid using =
a not-yet-loaded module binding.</div>
<div><br></div><div>Oh, but you probably meant that the module table form, =
besides being sugar, is written in a restricted language that cannot have e=
ffects other than to create module bindings -- cannot do document.write or =
document.createElementNS("script") or whatever. In that case we&#=
39;d want type=3D"harmony-module-table" or some such, and then su=
ch a script indeed would allow layout to proceed immediately, and not block=
rendering.</div>
<div><br></div><div>Thinking about it more, simple modules let authors bund=
le things in .js files, and src them with scripts. That's almost enough=
. Anything more, we do not want to standardize prematurely. Simple modules =
are really about lexical scope all the way up, and guaranteed errors (early=
errors, even), and static code partitioning with information hiding, and o=
f course the lexical-only module-binding namespace management.</div>
<div><br></div><div>Which is all good. Prefetching and packaging are separa=
ble issues, we should keep thinking about them but I'd hate to try to &=
quot;solve" them before considering simple modules as a proposal.</div=
>
<div><br></div><font color=3D"#888888"><div>/be</div></font></div><br>_____=
__________________________________________<br>
es-discuss mailing list<br>
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
<a href=3D"https://mail.mozilla.org/listinfo/es-discuss" target=3D"_blank">=
https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br><br>----------<br><span><font color=3D"#888">From: <b>David Herman</b> =
<span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.com" target=3D"_bla=
nk">dherman at mozilla.com</a>></span><br>Date: Mon, May 17, 2010 at 2:53 P=
M<br>
To: Brendan Eich <<a href=3D"mailto:brendan at mozilla.com" target=3D"_blan=
k">brendan at mozilla.com</a>><br>Cc: es-discuss Steen <<a href=3D"mailt=
o:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozilla.org</a>>,=
P T Withington <<a href=3D"mailto:ptw at pobox.com" target=3D"_blank">ptw@=
pobox.com</a>><br>
</font><br></span><br>Yes, sorry for the mixup. I should've written som=
ething like:<br>
<br>
=C2=A0 =C2=A0<script type=3D"harmony-module-configuration-table&qu=
ot;><br>
Agreed.<br>
Well put.<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>Kevin Curtis</b> <span dir=3D"ltr"><<a href=3D"mailto:kevinc1846 at gmail.=
com" target=3D"_blank">kevinc1846 at gmail.com</a>></span><br>
Date: Wed, May 19, 2010 at 12:59 AM<br>To: David Herman <<a href=3D"mail=
to:dherman at mozilla.com" target=3D"_blank">dherman at mozilla.com</a>><br>Cc=
: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D"=
_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>On Mon, May 17, 2010 at 4:07 PM, David Herman <<a =
href=3D"mailto:dherman at mozilla.com" target=3D"_blank">dherman at mozilla.com</=
a>> wrote:<br>
<br>
> [snip] For example, consider:<br>
That's surprising. Within a moduleloader I would have thought that<br>
same url meant the same static module. Across moduleloaders maybe not.<br>
<br>
For the following scenario:<br>
<script><br>
module ModA =3D "<a href=3D"http://acme.com/moda.js" target=3D"_blank"=
>http://acme.com/moda.js</a>";<br>
module ModB =3D "<a href=3D"http://acme.com/modb.js" target=3D"_blank"=
>http://acme.com/modb.js</a>";<br>
... source<br>
</script><br>
<br>
Both ModA and ModB use a utility module - that is the moda.js and<br>
modb.js files both contain:<br>
module ModUtils =3D "<a href=3D"http://widgets.com/modutils.js" target=
=3D"_blank">http://widgets.com/modutils.js</a>";<br>
<br>
I would have guessed that ModA and ModB are using the exact same<br>
static utility module. Firstly for efficiency - "hey this source has<b=
r>
been fetched and compiled already".<br>
<br>
But also, simple modules seem like 'traditional' modules. That is, =
if<br>
a top level variable is declared in a C source file, that variable<br>
occurs once in the resulting compiled image/program. Thus the source<br>
files (modules) author can reason about the (shared state) of the<br>
variable.<br>
<br>
However, if an ES module source can be declared multiple times (within<br>
a moduleloader) - doesn't it become harder for the author of the<br>
module to reason about a top level variable. If multiple instance of a<br>
module variable are required - then maybe an object should be used.<br>
<br>
Also, it seems unlikely that a new module source would be generated by<br>
a server within the context of a moduleloader fetching/compiling<br>
source. Maybe the rule should be - first source fetched for a url is<br>
the source used for subsequent module references.<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>Sam Tobin-Hochstadt</b> <span dir=3D"ltr"><<a href=3D"mailto:samth at ccs.=
neu.edu" target=3D"_blank">samth at ccs.neu.edu</a>></span><br>
Date: Wed, May 19, 2010 at 6:47 AM<br>To: Kevin Curtis <<a href=3D"mailt=
o:kevinc1846 at gmail.com" target=3D"_blank">kevinc1846 at gmail.com</a>><br>C=
c: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D=
"_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>The problem with this is that the web is not stable e=
nough. =C2=A0First, is<br>
it based on the string in the URL? =C2=A0If so, then is "Widgets.com&q=
uot; the<br>
same as "<a href=3D"http://widgets.com" target=3D"_blank">widgets.com<=
/a>"? =C2=A0What about "<a href=3D"http://www.widgets.com" target=
=3D"_blank">www.widgets.com</a>"? =C2=A0What if the url<br>
resolves to a different IP each time? =C2=A0Or if the source changes over<b=
r>
time?<br>
<br>
We feel that it's a bad idea to try to use addresses on the web to<br>
determine identity of modules. =C2=A0Instead, we based the naming system on=
<br>
lexical scope, and let the programmer manage resources on the web. =C2=A0If=
<br>
you want to share a common library with your context, then you refer<br>
to it by name, and the context can provide it the module under that<br>
name.<br>
<font color=3D"#888888">--<br>
sam th<br>
<a href=3D"mailto:samth at ccs.neu.edu" target=3D"_blank">samth at ccs.neu.edu</a=
><br>
</font><div><div></div></div><br>----------<br><span><font color=3D"#888">F=
rom: <b>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mo=
zilla.com" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Wed, May 19, 2010 at 7:04 AM<br>To: Kevin Curtis <<a href=3D"mailt=
o:kevinc1846 at gmail.com" target=3D"_blank">kevinc1846 at gmail.com</a>><br>C=
c: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D=
"_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>The problem is defining "same url." One opt=
ion is that "same" means "identical string" but then wh=
en <a href=3D"http://example.com/foo.html" target=3D"_blank">http://example=
.com/foo.html</a> says:<br>
<br>
=C2=A0 =C2=A0<script><br>
=C2=A0 =C2=A0module A =3D "<a href=3D"http://example.com/lib.js" targ=
et=3D"_blank">http://example.com/lib.js</a>";<br>
=C2=A0 =C2=A0module B =3D "./lib.js";<br>
=C2=A0 =C2=A0</script><br>
<br>
the programmer would be tempted to think those are the same URL. And yet a =
server has access to its request URL and can deliver entirely different bit=
s depending on exactly what was requested.<br>
<br>
So you could propose some sort of canonicalization that happens on the clie=
nt side, and say "same" means "same canonicalized string.&qu=
ot; But then the semantics depends on some non-trivial algorithm that happe=
ns away from view of the programmer.<br>
If they want to share a utility module, you pull it out into a place that&#=
39;s in scope for both ModA and ModB:<br>
<br>
=C2=A0 =C2=A0<script><br>
=C2=A0 =C2=A0module ModUtils =3D load "<a href=3D"http://acme.com/mod=
utils.js" target=3D"_blank">http://acme.com/modutils.js</a>";<br>
=C2=A0 =C2=A0module ModA =3D load "<a href=3D"http://acme.com/moda.js=
" target=3D"_blank">http://acme.com/moda.js</a>";<br>
=C2=A0 =C2=A0module ModB =3D load "<a href=3D"http://acme.com/modb.js=
" target=3D"_blank">http://acme.com/modb.js</a>";<br>
=C2=A0 =C2=A0...<br>
=C2=A0 =C2=A0</script><br>
I'm surprised to here you cite C as a precedent for modules, since C ha=
s no module system. All it has is #include, which is much harder to work wi=
th. The "load" semantics does still have the hazard of re-loading=
the same source (just as <script> does, BTW), but the scope is more =
tightly controlled; a loaded module is only sensitive to the modules in sco=
pe (no var-, let-, const- or function-bindings).<br>
<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>Kevin Curtis</b> <span dir=3D"ltr"><<a href=3D"mailto:kevinc1846 at gmail.=
com" target=3D"_blank">kevinc1846 at gmail.com</a>></span><br>
Date: Wed, May 19, 2010 at 11:34 AM<br>To: David Herman <<a href=3D"mail=
to:dherman at mozilla.com" target=3D"_blank">dherman at mozilla.com</a>><br>Cc=
: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D"=
_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>Ahh - thanks for this.<br>
<br>
So both the moda.js and modb.js source files can contain (for example):<br>
ModUtils.myfunc();<br>
<br>
And can import the exports of ModUtils:<br>
import ModUtils.myfunc;<br>
myfunc();<br>
<br>
<br>
Also, a script author can configure which modules they will use:<br>
For example use modules ModA and ModB - but not say - ModC and ModD.<br>
<script><br>
module Acme {<br>
=C2=A0// don't load the source files modc.js and modd.js - not used<br=
>
}<br>
Acme.ModA.myfunc();<br>
Acme.ModB.myfunc2();<br>
...<br>
</script><br>
<br>
Is it correct that a module declaration within a script tag only has<br>
scope within that script tag?<br>
That would be a surprise! No just the lexical concept.<br>
<font color=3D"#888888"><br>
--<br>
</font><div><div></div></div><br>----------<br><span><font color=3D"#888">F=
rom: <b>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mo=
zilla.com" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Wed, May 19, 2010 at 3:35 PM<br>To: Kevin Curtis <<a href=3D"mailt=
o:kevinc1846 at gmail.com" target=3D"_blank">kevinc1846 at gmail.com</a>><br>C=
c: es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D=
"_blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>Yes.<br>
No, each script is in scope for subsequent scripts. (The section "Top =
Level" in the strawman is the relevant part.) One of the enhancements =
to the current proposal, which we've considered but not worked out in d=
etail, would be the ability to create private modules.<br>
<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.c=
om" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Thu, May 20, 2010 at 9:56 AM<br>To: Mike Wilson <<a href=3D"mailto=
:mikewse at hotmail.com" target=3D"_blank">mikewse at hotmail.com</a>><br>Cc: =
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at mozi=
lla.org</a><br>
</font><br></span><br>
Hi Mike, sorry I overlooked this message.<br>
It's an automatic consequence of lexical scope. It's no different f=
rom functions. If you write:<br>
<br>
=C2=A0 =C2=A0function f() {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0function even(n) { ... odd(n-1) ... }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0function g() {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0function odd(n) { ... even(n-1) .=
.. }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0}<br>
<br>
you get a scope error, because |even| refers to |odd| which is not in scope=
. But if you put them both at the same level of scope, they can refer to ea=
ch other. Same deal with modules.<br>
<br>
Since MRL's and module names are distinct, there's no problem letti=
ng remote modules refer to one another, they just have to do so through agr=
eed-upon names. For example:<br>
<br>
=C2=A0 =C2=A0module Even =3D "<a href=3D"http://zombo.com/even.js" ta=
rget=3D"_blank">http://zombo.com/even.js</a>";<br>
=C2=A0 =C2=A0module Odd =3D "<a href=3D"http://realultimatepower.net/=
odd.js" target=3D"_blank">http://realultimatepower.net/odd.js</a>";<br=
>
<br>
By binding them both at the same level of scope, both even.js and odd.js ca=
n refer to Even and Odd.<br>
The offline-JS examples are mostly just suggestive; this question is left t=
o the (host-dependent) module loader to determine. Some offline-JS engines =
might prefer to have a module loader that can register top-level names impl=
icitly. It might also want to load these modules on demand (which is somewh=
at orthogonal), but this would likely only be desirable behavior for built-=
in libraries that have no observable side effects. (Laziness with side-effe=
cts is pain.)<br>
<br>
But all of this would require some host-dependent, built-in support; there&=
#39;s nothing in the spec per se that provides this functionality.<br>
The short answer is no: the contents are the body of the module.<br>
<br>
The long answer is that it depends on the module loader. Module loaders hav=
e hooks that can arbitrarily transform the contents of a module. So a modul=
e loader can decide on whatever format it wants.<br>
<br>
Note that when you say "an exception is thrown," this is a compil=
e/load-time exception. IOW, in the code being loaded, there's no observ=
able exception. But of course, with dynamic loading, one program's comp=
ile-time error is another program's run-time error. :)<br>
No. We avoided lazy loading in the semantics, because it'd be a hornets=
' nest on the web. Modules are eagerly evaluated in deterministic, top-=
to-bottom order. As I say above, offline-JS has different needs than web-JS=
, so in that context a JS engine may wish to provide a built-in custom modu=
le loader that can deal with the filesystem in more clever ways.<br>
<br>
As I replied to Kam Kasravi earlier in this thread, on-demand loading is ac=
hievable via explicit dynamic loading. We tried to be non-clever about doin=
g this stuff behind programmers' backs.<br>
No. There'd be no implicit loading on the web.<br>
I'm not sure I see what you're getting at, but IIUC, both of those =
examples are fine. You can always declare a new module binding that points =
to/aliases an existing module binding.<br>
It's a module body, which may contain nested module declarations, varia=
ble declarations, function declarations, statements, etc.<br>
Yes, but you wouldn't wanna do that. ;)<br>
The creator of the JSON library doesn't name it; the client names it. T=
he JSON module just contains the *body* of the module. This is crucial for =
the web: you can have millions of libraries without worrying about library =
name collisions.<br>
You can get partway there via:<br>
=C2=A0 =C2=A0import JSON.*;<br>
<br>
But yeah, it might be nice to have a shorthand that avoids the extra module=
binding. (I'd probably want the syntax to start with "import"=
; or "module").<br>
Me neither... I'll have to think about it.<br>
No, I was just positing some syntax for built-in MRL's. Maybe I should&=
#39;ve written something like<br>
<br>
=C2=A0 =C2=A0module JSON =3D load ('browser://JSON' || '<a hre=
f=3D"http://json.org/modules/json2.js'" target=3D"_blank">http://json.o=
rg/modules/json2.js'</a>);<br>
<br>
but I didn't want anyone to think I was making some specific proposal f=
or a new URL scheme or anything. This is one of those things that stands ou=
tside the jurisdiction of TC39 but would still want standardization. I thin=
k we're going to need some amount of (hopefully light) collaboration wi=
th a W3C committee.<br>
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=
:<br>
<br>
=C2=A0 =C2=A0MRL+(',') ::=3D MRL<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0MRL+(',')=
',' MRL<br>
<br>
Thanks for your feedback,<br>
Dave<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>David Herman</b> <span dir=3D"ltr"><<a href=3D"mailto:dherman at mozilla.c=
om" target=3D"_blank">dherman at mozilla.com</a>></span><br>
Date: Thu, May 20, 2010 at 11:25 AM<br>To: Mike Wilson <<a href=3D"mailt=
o:mikewse at hotmail.com" target=3D"_blank">mikewse at hotmail.com</a>><br>Cc:=
es-discuss Steen <<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_=
blank">es-discuss at mozilla.org</a>><br>
</font><br></span><br>PS If this is still unclear, just replace MRL+(',=
') with MRLList, and add the production:<br>
<br>
=C2=A0 =C2=A0MRLList ::=3D MRL<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0MRLList ',' MRL<=
br>
<br>
I'll do that in the spec to avoid this confusion in the future.<br>
<div><div></div></div><br>----------<br><span><font color=3D"#888">From: <b=
>Mike Wilson</b> <span dir=3D"ltr"><<a href=3D"mailto:mikewse at hotmail.co=
m" target=3D"_blank">mikewse at hotmail.com</a>></span><br>
Date: Thu, May 20, 2010 at 1:47 PM<br>To: David Herman <<a href=3D"mailt=
o:dherman at mozilla.com" target=3D"_blank">dherman at mozilla.com</a>><br>Cc:=
<a href=3D"mailto:es-discuss at mozilla.org" target=3D"_blank">es-discuss at moz=
illa.org</a><br>
</font><br></span><br>
Thanks for the detailed explanations, David. Here's a few follow-<br>
up questions (with "done" questions snipped out):<br>
<snip><br>
Agreed, but I was rather wondering about cases like:<br>
<br>
=C2=A0even.js<br>
=C2=A0 =C2=A0module Odd =3D "odd.js";<br>
=C2=A0 =C2=A0...<br>
=C2=A0odd.js<br>
=C2=A0 =C2=A0module Even =3D "even.js";<br>
=C2=A0 =C2=A0...<br>
<br>
More information about the es-discuss
mailing list