Thanks John for the list of things for which you need global variables,
indeed where Haskell already has global variables.
I think their disadvantages are overstated. Glasgow Haskell uses them lots,
as does the Workbench (I reckon about 80 or 100 times), as I suspect do
most large programs that have to do a lot of stateful things. It is very very
rare for me to be bitten by all these dangerous global variables around; in
fact the last time I can remember was 4 years ago or so when I forgot to
use NOINLINE. The other major disadvantage I think global variables have
is that there is nothing but global scope; it introduces the concept of
the "whole program" and you only have one copy of each global variable for
that program. My proposal deals with both these disadvantages. It also
is typesafe (unlike unsafePerformIO of course).
I'm aware that some people regard global variables as defiling the purity
of Haskell. It seems to me that the purity of Haskell was already defiled
when they introduced the IO monad. After all, you *could* implement global
variables in standard Haskell by writing stuff to files and back (though no
sane person would do this).
> stdout,stderr,stdin - people have brought up that these can be
> represented by stdout = 1, stdin = 0, and stderr = 2 and treat the
> integers as refering to magic built-in constants that refer to handles.
The traditional numbers would be stdout = 6, stdin = 5. If we're going to
degrade the wonderful language Haskell to make it less useful than FORTRAN 66,
we might as well use the FORTRAN 66 numbering scheme. While we're at it I
suggest replacing the current string notation by Holerith constants (which
are theoretically much nicer since you don't have to escape things), and tell
the compiler to reject all but the first 72 characters of each line.