On 5/17/07, 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?).
At this point in the discussion I always think Haskell could probably take a lesson from the evolution of object oriented programming. As I was taught, people starting to see modules as an important abstraction (yay, Haskell has those). Then people started to also realize that instead of just modules it would be useful to have abstract data types which could be instantiated many times and sort of encapsulate the things (state) you might store in a module (yay, Haskell has ADTs). Eventually, people put the two together, data types that also encapsulated functionality. Around this time, it was sort of like having modules that could be instantiated many times instead of once per program and objects were essentially born. Well, it seems to me that Haskell modules are actually very similar to singletons. Perhaps all these problems with modules having top level mutable state could be solved if Haskell modules were parameterizable at "instantiation"? I'm not saying we should turn the Haskell module system into an OO system, just that maybe it would be wise to borrow some ideas from that paradigm. Jason