[mercury-users] Mercury needs a Tutorial

[Richard A. O'Keefe]

	From daemon Fri Feb 12 22:01:15 1999
	Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22])
		by atlas.otago.ac.nz (8.9.0/8.9.0) with ESMTP id WAA18762
		for <ok at atlas.otago.ac.nz>; Fri, 12 Feb 1999 22:01:13 +1300 (NZDT)
	Received: (from majordomo at localhost) by mulga.cs.mu.OZ.AU
		id TAA28062 for mercury-users-list; Fri, 12 Feb 1999 19:31:28 +1100 (EST)
	Received: from mundook.cs.mu.OZ.AU (mundook.cs.mu.OZ.AU [128.250.37.154]) by mulga.cs.mu.OZ.AU with ESMTP
		id TAA28053 for <mercury-users at cs.mu.OZ.AU>; Fri, 12 Feb 1999 19:31:19 +1100 (EST)
	Received: (from fjh at localhost) by mundook.cs.mu.OZ.AU (8.8.5/8.7.3) id TAA13172; Fri, 12 Feb 1999 19:31:19 +1100 (EST)
	Message-ID: <19990212193118.16795 at mundook.cs.mu.OZ.AU>
	Date: Fri, 12 Feb 1999 19:31:18 +1100
	To: mercury-users at cs.mu.OZ.AU
	Subject: Re: [mercury-users] Mercury needs a Tutorial
	References: <199902110715.CAA14298 at rabbit.INS.CWRU.Edu> <19990211095711.A21557 at cam.sri.com> <19990211214753.40060 at mundook.cs.mu.OZ.AU> <19990212163251.O10449 at cs.mu.oz.au>
	Mime-Version: 1.0
	Content-Type: text/plain; charset=us-ascii
	X-Mailer: Mutt 0.88
	In-Reply-To: <19990212163251.O10449 at cs.mu.oz.au>; from Peter Schachte on Fri, Feb 12, 1999 at 04:32:51PM +1100
	Sender: owner-mercury-users at cs.mu.OZ.AU
	Precedence: bulk
	Reply-To: mercury-users at cs.mu.OZ.AU
	
	On 12-Feb-1999,  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.
	
Fergus Henderson <fjh at cs.mu.OZ.AU>
responded to 
Peter Schachte <schachte at cs.mu.OZ.AU>
about "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 note that the current Pascal standard has a similar feature:
	TO BEGIN DO <statement>;
as a declaration in a block is initialisation code, and
	TO END DO <statement>;
is finalisation code.  The only Pascal compiler I have ready access to
that actually _supports_ this is DEC Pascal, but it does work.  The
initialisation order is constrained by module dependencies.

I note that Ada, with its packages and the ability to initialise
variables using any expression including function calls, has the same
feature/problem, and that *controlling* "pre-elaboration order" has
historically been difficult for Ada programmers.  Pragmas are
provided to control things, because module dependency order was found
_not_ to be good enough.

	Trying to resolve the dependency ordering statically is a more
	difficult problem.

So the Ada experience is that it's *not* hard to resolve the dependency
order statically; the problem is doing it in a way that won't give the
programmer some nasty surprises, and that _is_ hard.

I suggest that this be put off for a bit.

	> 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.
	
Here again, history provides insight.  In principle, any top level
procedure in an Ada program could be 'main'; it's up to the environment
to specify the parameter profile of procedures which can be so used
(except that parameterless procedures are always eligible) and how they
are invoked.  I've used an Ada system which basically let you specify at
link time which of the candidates to pick, and no, it *wasn't* confusing,
because as a programmmer you never did focus on *any* of those procedures
as 'main'.  You looked at your program as a collection of packages (modules)
and it was the responsiblity of those packages to initialise themselves and
provide services, and then you wrote this little stubby things off to one
side to _use_ those services.  Smalltalk has been going just fine for
nearly two decades without having any 'main' (or to put it another way,
with just about _anything_ capable of being 'main').  Java allows any
class whatsoever to provide 'main', and it just is _not_ a problem;
almost all such 'main's are actually test drivers, and typically one
does or should focus on a program as a collection of services and then
write one or more tiny little things off to the side to invoke those
services.