[Haskell-cafe] One-shot? (was: Global variables and stuff)

[Adrian Hey]

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