[mercury-users] Mercury needs a Tutorial

[Peter Schachte]

On Fri, Feb 12, 1999 at 07:31:18PM +1100, Fergus Henderson wrote:
> 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.
>
> 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.

I was going to specify that the initializations of a module must be
executed before those of any module that depends on it, which still
seems like a good idea, except that it raises problems with circular
module dependencies.  Perhaps it would be adequate to disallow
initializations in two or more interdependent modules, or to state
that the order of executions of such initializations is undefined.

> The only time you need initialization is if you have global
> variables.

Global state of some sort, yes.

>  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.

There are two reasons I can see why this is inadequate.  Firstly, it's
a performance drain.  If some of the predicates and functions of the
module are lightweight, the extra check can be a significant
performance burden.  Secondly, the code can get to be a mess if every
externally visible predicate or function has to begin with a call to
something to ensure that the state is set up properly.  This gets a
bit worse when developers start (for performance reasons) to make
versions of these predicates and functions for internal use which
don't do those checks.  Not the end of the world, but certainly a
nuisance compared to puting in a single declaration in one place that
guarantees that the initialization is performed before any code in the
module is called.

Richard O'Keefe's mail also raises the issue of "termination" goals,
goals executed as the process shuts down, which also seem like a good
idea.

I'm surprised you object to this, since the Mercury implementation
itself is built on such a facility.

> > 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.

It need not cause any complication.  In the sort of situation I'm
thinking of, each module would probably contain a "main" anyway,
except that it'd be in a comment.  Better, I think, to include it as a
declaration.  As Richard points out, it's also a good way to include a
test harness in a module, rather than putting it somewhere else (where
it can get lost).


-- 
Peter Schachte                     We must not think that computation
mailto:schachte at cs.mu.OZ.AU        ... has has place only in numbers.
http://www.cs.mu.oz.au/~schachte/      -- Thomas Hobbes, 1655 
PGP: finger schachte at 128.250.37.3