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