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
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
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 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
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 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
16 matches
Mail list logo
