[Haskell] Global Variables and IO initializers

[Benjamin Franksen]

Let me add a few thoughts on the global variables problem and the proposed 
solutions.

1) I strongly disagree with ideas to execute IO actions implicitly in whatever 
defined or undefined sequence before or during main for whatever reasons. If 
initialization actions are necessary, they should always be performed 
explicitly from inside main. If modules or libraries need init actions to be 
performed, then such actions should be exported (and documented) in the 
normal way. The reasons are manyfold:

a) Explicit initialization means that the end-programmer has complete control 
over when and if such actions get executed, which is a Good Thing. It may 
very well happen, for example, that a program needs to perform some init 
action on its own before doing the one for an imported library. Or that one 
doesn't want to execute the library's init action at all because what one 
wants to use from it doesn't need the initialization.

b) Only explicitly called init actions may be parameterized. This means that 
any library that needs its initialization action to be parameterized by the 
user has to use the explicit variant anyway.

c) Implicitly executed init actions make the code harder to reason about.

d) Calling user code before main() was introduced in C++ (it is not possible 
in C). It took a while for programmers (myself included) to realize that the 
apparent elegance and convenience of this has a huge cost in maintainability, 
especially (but not only) in connection with shared libraries. AFAIK, using 
static objects with non-trivial constructors in libraries is nowadays deemed 
bad practice and rightly so. I know of one case where this has been the cause 
for inexplicable crashes when porting a library from one unix variant to 
another one. This delayed the release of the port for at least a year!

e) It has already been noted that if init actions from other modules are to be 
executed implicity, then the compiler needs to determine which module init 
actions to perform. The straight forward 'solution' is to use the import 
lists. This would imply that changing the import list of a module has 
potentially far reaching side-effects. This could lead to very obscure bugs.


2) I agree that avoiding global variables is often inconvenient. Even if we 
combine all of them into a single compound value ('globals'), at least this 
one value has to be threaded through a lot of functions that aren't in the 
least interested in them. Aside from making the code fragile against changes, 
it introduces a certain amount of noise into the code, making it harder to 
read and understand. I disagree though with what

On Wednesday 13 October 2004 00:33, John Meacham wrote:
> The issues are
> [...]
> 3) do we need it?
> [...]
> 3) yes. the
> {-# noinline :: fooVar #-}
> fooVar = unsafePerformIO $ newIORef 0
> is a very common idiom in real programs, and very difficult to work
> around not having.

It may be tedious and inconvenient to add a record of 'globals' as argument to 
all the functions involved, but difficult it is not. It is in fact so simple 
that it could be easily automated.

What I originally wanted to propose was therefore some sort of 
source-to-source program transformation that adds all the intermediate extra 
function arguments. Then I realized that this is almost exactly what the so 
called 'implicit parameters' extension to Haskell is all about, and that 
using them as a replacement for global variables has already been proposed by 
John Hughes (http://www.cs.chalmers.se/~rjmh/Globals.ps).

He notes in this paper that implicit parameters, as implemented in GHC, infect 
the types of all the involved functions with extra contexts. Although in 
principle this is exactly what we want, it implies that the addition of an 
implicit parameter (or changing its type) potentially invalidates a lot of 
function signatures (if these are given explicitly). This is unfortunate 
because it makes the code fragile and partly re-introduces the tedium we 
wanted to avoid in the first place.

What I've been asking myself is: Wouldn't it be possible for the compiler to 
silenty add the implicit parameter type constraints behind the scenes? It 
already does so for functions without a signature, so why not do it for 
functions with an explicit signature, too?

I realize that this would be a break with the Haskell tradition to *either* 
infer types *or* use the programmer given type signatures. Nevertheless, if 
this would work, we'd have a very clean *and* easily usable solution to the 
global variables problem.

Ben

P.S. I like the '?identifier' syntax for implicit parameters because it 
clearly marks such entities as dynamically bound instead of statically: you 
wouldn't even try to find the definition of such a thing in the surrounding 
scope.