Modules, Concatenation, and Better Solutions

Sam Tobin-Hochstadt samth at
Wed Oct 17 08:39:57 PDT 2012

On Tue, Oct 16, 2012 at 10:10 PM, David Herman <dherman at> wrote:
> On Oct 16, 2012, at 4:51 PM, John J Barton <johnjbarton at> wrote:
>> On Tue, Oct 16, 2012 at 2:58 PM, David Herman <dherman at> 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
samth at

More information about the es-discuss mailing list