Top level mutable data structures problem

Simon Peyton-Jones simonpj at
Wed Oct 20 11:38:54 EDT 2004

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
   and together comprise the "module initialisation action"

* When a program is started, the module initialisation actions of its
   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
   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


| -----Original Message-----
| From: glasgow-haskell-users-bounces at
| bounces at] On Behalf Of Simon Marlow
| Sent: 20 October 2004 15:47
| To: Adrian Hey; glasgow-haskell-users at
| 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
| 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
| the HTTP library).
| In any case, we're not going to rush to implement anything.  Discuss
| some more ;-)
| Cheers,
| 	Simon
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list