Global variables?

[Jon Cast]

Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> On 02-Feb-2003, Jon Cast <jcast@ou.edu> wrote:
> > Claus Reinke <claus.reinke@talk21.com> wrote:

> > > It is the programmer's responsibility to verify that none of these
> > > problems matter in the particular case of usage. Since many
> > > advances in compiler technology tend to invalidate those
> > > verifications, it is almost impossible to guarantee safety in such
> > > cases

> > Even with sufficiently liberal use of {-# NOINLINE #-}?

> Haskell Report, Appendix E (Compiler Pragmas): "An implementation is
> not required to respect any pragma".

Right.  So perhaps the Haskell Report should take more notice of global
variables.  But considering that it doesn't, and there is no completely
portable mechanism for getting global mutables, it seems to me that
bashing any alternative as non-portable is missing the point :)

> > > There you went.. into one of the many available traps in this
> > > mine-field:

> > > You argue that unallocated IORefs don't matter as long as "the"
> > > IORef is allocated before it is dereferenced. But that's just part
> > > of the problem - what about inlining globalVar, creating multiple
> > > IORefs?

> > {-# NOINLINE globalVar #-} :)

> What about creating two copies of globalVar, neither of them inlined?
> A compiler could do that to improve performance on some architectures,
> e.g. by allowing the function to be called via a short jump
> instruction rather than a long jump instruction.

See above.

> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
> The University of Melbourne         |  of excellence is a lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.