On Tue, Oct 16, 2012 at 10:10 PM, David Herman <[email protected]> wrote: > On Oct 16, 2012, at 4:51 PM, John J Barton <[email protected]> > wrote: > >> On Tue, Oct 16, 2012 at 2:58 PM, David Herman <[email protected]> wrote: >>> The weird thing about (a) is that code that appears to be straight-line >>> actually executes in somewhat more unpredictable (although deterministic) >>> order. >> >> I guess if we can handle deeply nested callbacks, event handlers, and >> promises, then this is a pretty tame as weird things go. Are you are >> saying is that the body of the module does not run until we need its >> content? So dependents pull in their dependencies and modules that are >> not needed are not executed. That's what we want right? > > My main concern comes from the fact that module initialization code can have > arbitrary side effects: modify variables or shared objects, update the DOM, > change some CSS, send an XHR request to fire a nuclear missile (HTTP UPDATE > please -- I like my global thermonuclear war RESTful), ... You don't > generally want languages to cause side effects to happen in unpredictable > orders. If modules are executed on demand, you can't as easily predict when > they are going to execute. (This is an instance of the general rule of PL > design: lazy execution and side effects don't mix.) > > But, that said, the execution of the modules isn't triggered by arbitrary > control flow of the program, just the syntactically restricted top-level > imports. So that probably makes it pretty tame. > > Still, I'm interested in hearing Sam's and Andreas Rossberg's input on this.
I think (a) is the better choice. It means that reordering source files with only modules in them doesn't change your program, and it supports concatenation/minification better, which I think are likely to be with us for a long time. Also, I think Claus' analogy to functions is the right one, with the proviso that the modules are run as soon as as we start running the module that imports them. -- sam th [email protected] _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
