Top level mutable data structures problem

[Simon Peyton-Jones]

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 at haskell.org
[mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Simon Marlow
| Sent: 20 October 2004 15:47
| To: Adrian Hey; glasgow-haskell-users at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users