[Haskell-cafe] global variables

[Adrian Hey]

Jules Bean wrote:
>> BTW, this is the commonly the subject of flame wars on the Haskell
>> mailing lists because there appear to be many who passionately believe
>> and assert that so called "global variables" are (at best) unnecessary
>> and (at worst) are "evil". These people are quite simply wrong and
>> should be ignored :-)
> 
> Adrian Hey is not only wrong, but actually evil. He should be ignored. :-)

I am right, I might well be evil, and if past experience is anything to
go by I already know that I will be ignored. We've been talking about
this problem for years, but nothing is ever done about it (a solution to
this problem isn't even on the agenda for Haskell' AFIAK).

> The above hack is not actually Haskell. It's a hack, and it depends on 
> the particular implementation characteristics of GHC. It is not 
> unreasonable to imagine that a future GHC might contain different 
> compilation techniques (I hesitate to use the word 'optimisations' 
> because that sounds like something easy to turn off) which invalidate 
> the technique in other ways or make it dangerous.

Well of course, that's why something needs to be done about this. Just
being in a state of complete denial regarding the reality of this
problem won't make it go away.

>> They are necessary because they are the only way to ensure important
>> safety properties of many IO APIs.
> 
> That's a bold claim. It's very hard to prove that things don't exist. 
> (That is, that other ways to ensure these safety properties don't 
> exist). In snipped text you comment that the problems are often in 
> low-level FFI library code: this makes me wonder if the real culprit 
> doesn't lie at the FFI-haskell boundary. Perhaps there are good ways to 
> specify this kind of invariant there.

No. Even if we stripped away all other code apart from the Haskell rts
itself (OS, device drivers etc) and performed your IO entirely in
Haskell (just using peek and poke on bare hardware), you'd still need
top level mutable state to implement common IO API's (e.g. The socket
API, does anybody really believe this is entirely stateless?).

I wouldn't dispute the assertion that at the level of complete programs
or processes, implementations that don't use "global variables" are
possible. But this does not hold at the level of individual IO library
API's. If we want to keep our software *modular* (I take we do), then
we need top level mutable state.

>> If you want to see more examples of the use of the unsafePerformIO
>> hack you need only look at the source code of the current base
>> package (you'll find a dozen or so uses of this hack to create
>> top level mutable state).
> 
> All of these are, in a sense, failings. Because unsafePerformIO is not 
> haskell, and we'd like base to be a haskell library. Not a GHC library.

But what's the problem?
Is it the use of "global variables"?
Or is it the use of the unsafePerformIO hack to create them?

Regards
--
Adrian Hey