So, assuming Math has no dependencies (just to make this shorter), the
sequence of events:
* Load Foo, convert to AST, find from usage.
* Load Math
* Compile Math
* Evaluate Math
* Inspect Math's exported module value for properties
* Modify the compiled structure for Foo to convert import * to
I just noticed that James' original email had two more items:
* The 'Math' module is evaluated before Foo is evaluated.
* Only the properties on Math that are available at the time of Foo's
execution are bound to local variables via the import *.
which puts it in line with the first option I
On Thu, Apr 5, 2012 at 11:23 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Thu, Apr 5, 2012 at 10:01 AM, James Burke jrbu...@gmail.com wrote:
So, assuming Math has no dependencies (just to make this shorter), the
sequence of events:
* Load Foo, convert to AST, find from usage.
On Fri, Apr 6, 2012 at 4:54 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:
On Thu, Apr 5, 2012 at 11:23 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Thu, Apr 5, 2012 at 10:01 AM, James Burke jrbu...@gmail.com wrote:
So, assuming Math has no dependencies (just to make
On Fri, Apr 6, 2012 at 2:04 AM, Claus Reinke claus.rei...@talk21.com wrote:
I just noticed that James' original email had two more items:
* The 'Math' module is evaluated before Foo is evaluated.
* Only the properties on Math that are available at the time of Foo's
execution are bound to
On Fri, Apr 6, 2012 at 4:54 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
The properties available to `Foo` are exactly the ones declared with
`export` in `Math`. I don't think that should be a surprise to
anyone -- that's what `export` is for.
However, it is the case that the evaluation
On Sat, Mar 31, 2012 at 6:47 PM, David Herman dher...@mozilla.com wrote:
Static checking is a continuum. It's mathematically proven (e.g., Rice's
theorem) that there are tons of things a computer just can't do for you in
general. So we have to pick and choose which are the things that can be
On Thu, Apr 5, 2012 at 10:01 AM, James Burke jrbu...@gmail.com wrote:
So, assuming Math has no dependencies (just to make this shorter), the
sequence of events:
* Load Foo, convert to AST, find from usage.
* Load Math
* Compile Math
* Evaluate Math
* Inspect Math's exported module value
Libraries will need to work in old world browsers for a few years.
Possible solutions:
a) Ask libraries to provide a lib.es-next.js version of themselves in
addition to the old world version, so that compile time linking with
new module/import syntax can be used.
b) Have a way for the library
I think you misunderstand the relationship between what Dave said, and
The purpose of my questions is to remove misunderstandings -
it is entirely possible that some of them are on my side!-)
If you have dynamic modules, you can't use them to export any
compile-time
constructs, like macros,
On 31 March 2012 21:30, David Herman dher...@mozilla.com wrote:
Yeah, I've thought about auto-appending .js. I think you're right that
it opens up the possibility to be a little more abstract.
FWIW -- the CommonJS convention of auto-appending .js has been a real boon
to us when writing GPSEE
On 1 April 2012 08:22, Wes Garland w...@page.ca wrote:
the JS application developer never needs to know what language the
application is written in.
Sorry, what language the *module* is written in.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
If you have dynamic modules, you can't use them to export any
compile-time constructs, like macros, static operator overloading,
custom literals, or static types. If you load a module at runtime,
then it's too late by the time you actually have the module to use
it for anything at compile
On Sat, Mar 31, 2012 at 6:30 PM, David Herman dher...@mozilla.com wrote:
baseUrl + ID + .js
Yeah, I've thought about auto-appending .js. I think you're right that
it opens up the possibility to be a little more abstract.
Auto-appending makes the API less abstract:the arguments must be
I agree with you, auto-appending is too concrete and JS-only. We can't
use auto-append as a fallback since it's ambiguous (foo and foo.js could
exist) and we shouldn't prefer foo based on existence (we'd have to GET
twice or otherwise probe for existence). We want names not to depend on
I think you misunderstand the relationship between what Dave said, and
the type Dynamic work. Also, your later comments about staging are
unrelated to this issue, and wrong with regard to the module design.
More detail below ...
On Sun, Apr 1, 2012 at 10:52 AM, Claus Reinke
On Sun, Apr 1, 2012 at 11:33 AM, Brendan Eich bren...@mozilla.org wrote:
I agree with you, auto-appending is too concrete and JS-only. We can't use
auto-append as a fallback since it's ambiguous (foo and foo.js could exist)
and we shouldn't prefer foo based on existence (we'd have to GET twice
On Fri, Mar 30, 2012 at 3:25 PM, James Burke jrbu...@gmail.com wrote:
---
5) Compile time linking
---
There is a tension between the runtime calls like System.load and the
compile time linking of the module/import syntax. The runtime
capabilities cannot be removed. However,
Hi James,
I'd like to add some counter points.
---
1) Multiple mrls for System.load():
---
I think it makes sense to have this convenience, even though it's probably
better practice to use the static syntax as much as possible. For
performance and tooling support. There's some
On Fri, Mar 30, 2012 at 3:25 PM, James Burke jrbu...@gmail.com wrote:
[snip]
The module_loaders API has a way to do a runtime module registration, but as
I understand it, it means that a consumer of my library then needs to then
use the System.load() API to get a hold of it.
My
On Sat, Mar 31, 2012 at 8:54 AM, Sebastian Markbåge
sebast...@calyptus.eu wrote:
Hi James,
I'd like to add some counter points.
---
1) Multiple mrls for System.load():
---
I think it makes sense to have this convenience, even though it's probably
better practice to use
On Sat, Mar 31, 2012 at 11:02 AM, Luke Hoban lu...@microsoft.com wrote:
On Fri, Mar 30, 2012 at 3:25 PM, James Burke jrbu...@gmail.com wrote:
[snip]
The module_loaders API has a way to do a runtime module registration, but
as I understand it, it means that a consumer of my library then needs
Hi James,
1) Multiple mrls for System.load():
System.load(jquery.js, underscore.js, function ($, _) {})
or
System.load([jquery.js, underscore.js], function ($, _) {})
Makes sense. The former is a bit muckier but more convenient than the latter.
I'll play with the alternatives, thanks.
---
Benefits of compile time binding
---
This is what I need help in understanding. The benefits I have heard so far:
1) Being able to check export names/types. As mentioned, this feels
like a very shallow benefit, since it does not apply to properties
outside of the
On Mar 31, 2012, at 6:47 PM, David Herman wrote:
This can be and has been done in other dynamically typed languages [1], and
it can be done for JS, too.
[1] http://www.ccs.neu.edu/home/stamourv/papers/numeric-tower.pdf
___
es-discuss mailing list
On Mar 31, 2012, at 11:11 AM, James Burke wrote:
We should try for the equivalent of import *, sorry if I was too short
on this point. I'll expand what I meant:
I think it should be a runtime-like thing (probably using the wrong
word there), and just allow it for any object via
First I'll give some smaller bits of feedback, and then at the end
propose something that integrates all the feedback.
I hope they can considered independently: if you do not like the
proposal, feel free to just take in the feedback. I tried to order the
feedback in order of craziness with the
27 matches
Mail list logo
