[Haskell-cafe] Re: Global Variables and IO initializers

Peter Simons simons at cryp.to
Mon Nov 8 16:17:37 EST 2004


Adrian Hey writes:

 >> I don't see any value in problems that are
 >> specifically designed so that they can be solved
 >> only with a global entity.

 > Even if it was true that I had "specifically
 > designed" this problem, it's existance is of some
 > interest I think.

Perhaps my choice of words wasn't really good. I am
sorry. What I meant to say is that I have never once
_needed_ a global variable yet. Never. On the other
hand, there were plenty of occasions where I had
trouble with global variables in other people's code.
I'll readily admit that a safe way to implement them in
Haskell is probably an interesting research subject,
but I honestly don't expect to be using that feature
any time soon. It's a completely abstract concept for
me; I associate no practical value with it.


 > [Creating top level "things with identity" is] what
 > many in this thread assert is bad code, yourself
 > included it seems. Yet this is widely used in many
 > programs and libraries, even in ghc itself I
 > believe. Not to mention stdin etc.. (again).

Right, but it is by no means _necessary_ to have a
global 'stdin'. It could equally well be defined as

  stdin :: IO Handle

and it would work just the same. The fact that it isn't
implemented this way is for historical reasons, IMHO,
not because it's a good idea.


 >> Because code like that is very hard to get right
 >> and very hard to maintain, and I don't want to use
 >> library code that uses this technique if I can
 >> avoid it.

 > This is dogma I think.

Yes, you are right. Nonetheless, it is a dogma that's
not just arbitrary; it is motivated by experience with
real-life code. Just ask the C++ folks about the
wonders of global variables that are actually complex
classes with a constructor and a destructor. You
wouldn't believe through what kind of hoops you have to
jump if you want to write reliable code that has to
deal with this. For instance: Where do you catch
exceptions a constructor throws that is executed before
your main() routine is? How do you deal with exceptions
that are thrown after your main routine has _ended_?

The effect is that the language is full of strange and
very counter-intuitive mechanisms, just so that they
can implement something which -- in _my_ opinion -- is
completely useless to begin with!


 > There are many libraries you will need to try to
 > avoid using if this is really your position.

Let's say ... I try to compromise rarely, but I do have
to compromise, unfortunately. In fact, I have to admit
that my own Haskell code contains unsafePerformIO at
the occasion, too. Not that I'd need it, but I am too
damn lazy as well. :-)

Peter



More information about the Haskell-Cafe mailing list