On Friday 12 Nov 2004 3:20 pm, Keean Schupke wrote:
Adrian Hey wrote:
The latter is probably true, in a strict technical sense. But I can't see a way to live without them and keep modularity. In any case, I don't think there's any reason to force programmers "wear the hair shirt" in this respect (other than dogma and superstitious fear about the evils of "global variables" :-)
I agree about not wearing a hair-shirt, but how do you propose to solve the multiple import problem: B imports A, C imports A, D imports B & C. Now the top level inits (a <- computation) in A, do they happen once, defining the same init A.a, do they happen twice, perhaps initialising B.A.a and C.A.a, do they happen twice, meaning that 'a' may have different values depending on whether it is accessed from B or C? for example:
I'm not sure I understand what problem you think there is. Are the inits you're talking about module inits? If so, I don't think there's a problem, for several reasons. The idea under discussion is that a top level (x <- newThing) should be lazy, (no action at all occurs until value of x is demanded). IOW, it's exactly the same as the current unsafePerformIO hack, but not unsafe because the compiler knows the semantics. So there is no implied "module initialisation".
module A where a <- newChan 0
module B where import A b <- do {writeChan A.a 7;return ()}
module C import A c <- do {writeChan A.a 6;return ()}
module D import A import B
d <- readChan A.a
does this mean the same as:
module D' import B import A
d <- readChan A.a
Should values really depend on the order of includes?
No, and they don't. Firstly, since the values of neither b or c are demanded, no writes will occur. Secondly, ordering is not dependent on import ordering, it's depencency ordering only. Assuming laziness, actions are performed as and when the corresponding TWI's are required (perhaps never). Thirdly, ordering doesn't matter anyway. The point of the restricted monad proposal (SafeIO or whatever), was to address precisely this ordering issue. With SafeIO ordering doesn't matter because you cannot perform any IO. All you can do is create IORefs (MVars etc..). You can't read or write them, nor can you do any other IO. So assuming we're using this monad for <- bindings, you wouldn't be able to use readChan or writeChan in any case. Regards -- Adrian Hey