Lots of schemes have been discussed. The one I understand best is: * Modules can contain top-level bindings like x <- e where e:: IO t, and x::t * The IO actions from these bindings are composed, in order of appearance, and together comprise the "module initialisation action" * When a program is started, the module initialisation actions of its modules run, in an order that respects module dependencies. * "Respecting module dependencies" means that if M imports N (directly or indirectly) then N's initialisation is done before M's. Hi-boot recursive dependencies are not taken into account; that's where any module loops are broken That's simple, and easy to describe. It does not fully prescribe the initialisation order, but the programmer can constrain the order as much as required, by adding 'import' declarations. That's way better than the situation today, where the moment at which these actions take place is totally unpredictable. As Simon M says, don't hold your breath... but I'd be interested to know a) whether this story commands a consensus b) how much happier your life would be if it were implemented Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Simon Marlow | Sent: 20 October 2004 15:47 | To: Adrian Hey; glasgow-haskell-users@haskell.org | Subject: RE: Top level mutable data structures problem | | On 20 October 2004 14:36, Adrian Hey wrote: | | > [Excuse me for moving this discussion to the ghc mailing list, | > but it seems the appropriate place, seeing as ghc is where | > any solution will happen first in all probability.] | > | > I've noticed that the neither of the two Simons has expressed an | > opinion re. the discussions on this issue that occurred on the | > Haskell mailing list over the weekend. So I'd like to ask what's | > happening (or likely to happen) about this, if anything? | | I liked the original idea. I'm not sure if I agree with the argument | that allowing fully-fledged IO actions in the initialisation of a module | is unsafe. I agree that it is a little opaque, in the sense that one | can't easily tell whether a particular init action is going to run or | not. | | On the other hand, instances currently have the same "problem": you | can't tell what instances are in scope in your module without looking | through the transitive closure of modules you import, including | libraries, which you might not have source code for. | | The proposed scheme wouldn't allow forcing an ordering on init actions | between two modules (eg. initialise the network library, then initialise | the HTTP library). | | In any case, we're not going to rush to implement anything. Discuss it | some more ;-) | | Cheers, | Simon | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users