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
On Wednesday 20 Oct 2004 3:46 pm, Simon Marlow wrote:
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.
I'm not sure who was arguing that (not me anyway :-). I think the argument was about whether or not there should be any such thing as "module initialisation" at all, or at least that's what concerns me most. (I don't think there should be).
In any case, we're not going to rush to implement anything. Discuss it some more ;-)
Good plan :-) FWIW, at the moment the executive summary of MHO is that the laziness and unpredictability of the unsafePerformIO hack is the one thing I like about it and want to keep. What I don't like about it is the unsafety. The unsafety I'm talking about is _not_ that that arises from allowing arbitrary IO operations. I'm talking about the fact that the compiler cannot be relied upon to generate code that accurately reflects the programmers intentions without using NOINLINE pragma and -fno-cse flag (the latter applying to an entire module). There's also the (IMO) secondary issue of whether or not the IO actions allowed during construction should be constrained in any way (e.g. using type system tricks). I suggested a simple (perhaps naive) way to to this (SafeIO monad), but I don't have any particularly strong views on this either way. Just relying on programmers to use some common sense seems fine to me also (this is what's currently done for finalisers for example). Regards -- Adrian Hey
On Wed, Oct 20, 2004 at 03:46:47PM +0100, Simon Marlow wrote:
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.
Allowing IO actions in the initialization of a module then requires the ability to determine what order these initializations happen in. Ocaml does this, and it requires that all modules be specified in a proper order to the compiler. Dave
participants (3)
-
Adrian Hey -
David Brown -
Simon Marlow