On Fri, Apr 6, 2012 at 4:54 AM, Sam Tobin-Hochstadt 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 of `Math` an
On Fri, Apr 6, 2012 at 2:04 AM, Claus Reinke 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 local variab
On Fri, Apr 6, 2012 at 4:54 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Apr 5, 2012 at 11:23 PM, John J Barton
> wrote:
> >
> >
> > On Thu, Apr 5, 2012 at 10:01 AM, James Burke wrote:
> >>
> >>
> >> So, assuming Math has no dependencies (just to make this shorter), the
> >> sequence of events:
> >>
On Thu, Apr 5, 2012 at 11:23 PM, John J Barton
wrote:
>
>
> On Thu, Apr 5, 2012 at 10:01 AM, James Burke 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 M
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
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 *" t
On Thu, Apr 5, 2012 at 10:01 AM, James Burke 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 for pro
On Sat, Mar 31, 2012 at 6:47 PM, David Herman 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 done
> for us th
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, st
On Sun, Apr 1, 2012 at 11:33 AM, Brendan Eich 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 or
> otherwise p
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 wrote:
>> If you have
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
whether
On Sat, Mar 31, 2012 at 6:30 PM, David Herman 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 JS. Tha
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 time.
On 1 April 2012 08:22, Wes Garland 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
__
On 31 March 2012 21:30, David Herman 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 modules. We to
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 destruct
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
e
> ---
> 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 th
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,
On Sat, Mar 31, 2012 at 11:02 AM, Luke Hoban wrote:
>>> On Fri, Mar 30, 2012 at 3:25 PM, James Burke 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 Syst
On Sat, Mar 31, 2012 at 8:54 AM, Sebastian Markbåge
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 the static syn
>> On Fri, Mar 30, 2012 at 3:25 PM, James Burke 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 understanding was t
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 pr
On Fri, Mar 30, 2012 at 3:25 PM, James Burke 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, I believe i
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 f
27 matches
Mail list logo
