[Haskell-cafe] Re: Global Variables and IO initializers
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. :-)
More information about the Haskell-Cafe