[mercury-users] Mercury needs a Tutorial

[Fergus Henderson]

On 12-Feb-1999, Peter Schachte <schachte at cs.mu.OZ.AU> wrote:
> While you're doing this, it would be worth also considering adding
> initialization goals.  I don't have a syntax proposal, but it would
> want to be like specifying a main, except that all initializations
> would be executed, in some unspecified order, before the main is
> executed, and the input io__state of the first initialization would be
> real initial io__state, the input io__state for each other
> initialization would the output io__state of the previous one, and the
> input io__state of the main would be the output io__state of the final
> initialization.  When you need this facility, it's very unpleasant to
> try to do without it.

The difficulty with this is order of initialization.  Having the order
of I/O unspecified seems like a bad idea, not only from a purist point
of view, but also from a pragmist viewpoint: you can easily get into
trouble where the initialization for one module depends on the
initialization for some other module already having been run.

The only time you need initialization is if you have global
variables.  In that case, you can use a boolean global
variable to record whether the initialization has been done yet,
and each access can check that variable and do the initialization
if necessary.  This has the effect of resolvoing the initialization
ordering dependencies dynamically, at runtime.

Trying to resolve the dependency ordering statically is a more
difficult problem.  C++ tried to solve that problem, but failed.  The
standards committee didn't manage to find a workable solution to the
order of initialization problem, so they left the order unspecified.
This made the feature to unreliable to use, so recommended practice in
C++ is to avoid using the feature (constructors for global variables) at all.
Instead, programmers are encouraged to use functions returning a
reference to a static variable.  A static variable is initialized the
first time its scope is entered, and so the compiler implements this
using a hidden boolean, just as I described above.

> Another thing to consider is that it's sometimes convenient to have
> several mains in a single program

I don't think this one is worth the trouble.
Having multiple mains in a single program could easily
cause confusion.  I think it's best to keep things simple.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh at 128.250.37.3        |     -- leaked Microsoft memo.