[Haskell-cafe] global variables

[Jason Dagit]

On 5/17/07, Adrian Hey <ahey at iee.org> wrote:
> 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