Top level mutable data structures problem

[Adrian Hey]

On Wednesday 20 Oct 2004 4:38 pm, Simon Peyton-Jones wrote:
> * "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

I was hoping that one day Hi-boot would not be neccessary. So I'm not
sure what ordering you'd get in that case with what's proposed. But
let's not worry about that right now :-)

> As Simon M says, don't hold your breath... but I'd be interested to know
>
> a) whether this story commands a consensus

Well actually at the moment I don't agree with this proposal, but I may be
in a minority of one. That's why I wanted to find out what's happening.
(See my response to Simon M for my reasons).

Wolfgang definitely seems to want this though, but I'd better leave it to
him to explain why.

IMO the one good thing about the unsafePerformIO hack is that there are no
guarantees about whether or when the corresponding actions will occur.
This fact is a powerful disinsentive to abuse of or over reliance on this
feature I think. I.E. People are not likely to use it for any purpose
other than the creation of top level mutable data structures. In particular
they can't rely on any "side effects" of creation if there's no guarantee
that creation will ever occur. (Well not unless they use `seq` somewhere
to force it).

> b) how much happier your life would be if it were implemented

Well IME there are two common uses of unsafePerformIO in my progs..
 1- Creation of top level mutable data structures (which may
    live outside Haskell land sometimes).
 2- As a "type cast" for FFI functions which really are pure,
    but have type IO anyway because of marshalling etc..

I would really like a solution to useage 1 that didn't use unsafePerformIO,
because it really is _unsafe_. Useage 2 is ugly perhaps, but AFAICS is
perfectly safe (provided the foreign function in question really is a
function), so doesn't require the use of NOINLINE, -fno-cse etc.

Regards
--
Adrian Hey