Wolfgang Thaller wrote:
2) Evaluation order.
That's what everyone has been fighting about. [...]
The basic idea is that your entire program behaves as if in a giant 'mdo' block, ordered in module dependency order.
What is module dependency order? There's no such thing when there are circular dependencies, and when there aren't any, it might still depend on the order of import directives, which is probably not something I want program semantics to depend on. I feel that In a large program, you'll probably get more surprises from this.
The Modula-3 language specification gives one reasonable definition: ===Begin excerpt. From http://research.compaq.com/SRC/m3defn/html/complete.html#idx.148 : 2.5.6 Initialization The order of execution of the modules in a program is constrained by the following rule: If module M depends on module N and N does not depend on M, then N's body will be executed before M's body, where: A module M depends on a module N if M uses an interface that N exports or if M depends on a module that depends on N. A module M uses an interface I if M imports or exports I or if M uses an interface that (directly or indirectly) imports I. Except for this constraint, the order of execution is implementation-dependent. ===End excerpt. According to the above constraint, the initialization order is implementation-defined in the case of circular dependencies. Note, too, that the order of import directives in a module does not affect the partial order imposed by the above constraint. (The above was delayed by the haskell mailing list anti-spam measures. Anyway, looks like the above rule is entirely consistent with Simon Marlow's description of what ghc already implements for initialization order.) -Antony