The easiest way to think about it is to imagine the fully loaded bits of the whole program as if they were just declared inline in one big file. Then the total order is manifest -- it's just the order they appear in the program. The non-deterministic I/O performed by the compiler is just an internal detail of the engine's implementation that doesn't leak into the semantics.
Or here's a sort of more operational way to think about it: Start with the outermost program. It declares a bunch of modules, some of which are loaded from external files. But the declaration order of this first level of sub-modules is manifestly ordered in the program. Now maybe the compiler loads those files in parallel or out of order, but ultimately it has all the bits. Within each loaded file, the order of modules is (recursively now) itself totally ordered. Dave On Jan 27, 2011, at 11:30 AM, Kris Kowal wrote: > On Thu, Jan 27, 2011 at 9:14 AM, David Herman <dher...@mozilla.com> wrote: >> …but it is required to evaluate them in their declared order, >> deterministically. > > Would you explain how declaration order is inferred from the contents > of the unordered of files? > > It's clear that the order is at least partially knowable through the > order of module declarations within a single file, and that "load" > directives would be replaced with a nest of modules, which is similar > in effect to loading on demand if the load directive is considered a > point of demand at run-time. And we're guaranteed that there are no > files that would be loaded that are not reachable through transitive > "load" directives. I suppose I've answered my question, if all my > assumptions are correct. > > Kris Kowal _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
