mercury/RELEASE_NOTES

We are pleased to announce the release of version 0.5 of the Mercury system.

Mercury is a new, purely declarative logic programming language.
Like Prolog and other existing logic programming languages, it is a
very high-level language that allows programmers to concentrate on the
problem rather than the low-level details such as memory management. 
Unlike Prolog, which is oriented towards exploratory programming,
Mercury is designed for the construction of large, reliable, efficient
software systems by teams of programmers.  As a consequence,
programming in Mercury has a different flavour than programming in
Prolog.

Here's what new in release 0.5:

* We now support committed choice nondeterminism in a logical and declarative
  fashion, using the new determinism categories `cc_nondet' and `cc_multi'.
  Like `nondet' and `multi' respectively, they specify that a predicate
  may have more than one solution, but they convey the additional
  assertion that the predicate will only be used in contexts in which
  only one solution is needed.  The compiler will check that all uses
  of the predicate satisfy this requirement.  Having proven the
  assertion to be correct, the compiler can then generate much more
  efficient code for the predicate.  By pushing pruning inwards, the
  compiler can often avoid creating choice points at all.

* We now check for backtracking over unique modes.
  (This may potentially break some programs using unique modes in ways
  that the compiler can't prove are safe.  In such cases, replacing
  `multi' with `cc_multi' should solve the problem.  If you have any
  trouble with this, we'll be happy to help you.)
  We have also added "mostly unique" modes, which provide support
  for backtrackable destructive update.
  See the Mercury language reference manual.

* We now provide genuinue arrays with destructive update.
  See the library module `uniq_array'.  (Warning: this has not had
  much testing.  The interface is not yet stable.)

* We now support interfacing to C code.
  See the documentation in the Mercury language reference manual.

* There is now an `inline' pragma which you can use as a hint to the
  compiler to inline a particular predicate.

* We've ported the system to HPUX (thanks to Gertjan van Noord
  and especially Eero Pajarre).

* We now support shared libraries for IRIX 5.

* We now allow the use of compilers other than gcc -
  see the user's guide for details.
  We don't recommend the use of compilers other than gcc,
  since the inability to use gcc's special features will
  most likely lead to much less efficient code.

* To complement our source distribution, we now also provide binary
  distributions for a variety of platforms.  Installation should be
  quick and easy.

* Various other minor improvements:
  - In portable C mode, we now generate better code for loops.
  - We've made a few other minor improvements in the generated code.
  - Unary plus and minus are now implemented.
  - Updated the documentation to reflect changes in unique modes,
  - Corrected a lot of typos in the documentation.
  - Fixed quite a few bugs.

* Parts of the library module `std_util' have been moved into separate
  modules `assoc_list' and `bool'; if you have existing code which
  used those parts of `std_util', you may need to add `import_module'
  declarations to import `assoc_list' and/or `bool'.

The main features of Mercury are:

     o  Mercury is purely declarative: predicates in Mercury do not
        have non-logical side effects.

	Mercury does I/O through built-in and library predicates that
	take an old state of the world and some other parameters, and
	return a new state of the world and possibly some other
	results.  The language requires that the input argument
	representing the old state of the world be the last reference
	to the old state of the world, thus allowing it the state of
	the world to be updated destructively.  The language also
	requires that I/O take place only in parts of the program where
	backtracking will not be needed.

	Mercury handles dynamic data structures not through Prolog's
	assert/retract but by providing several abstract data types in
	the standard Mercury library that manage collections of items
	with different operations and tradeoffs.  Being a compiled
	language, Mercury does not have any means for altering the
	program at runtime, although we may later provide facilities
	for adding code to a running program.

     o  Mercury is a strongly typed language.  Mercury's type system is
	based on many-sorted logic with parametric polymorphism, very
	similar to the type systems of modern functional languages such
	as ML and Haskell.  Programmers must declare the types they
	need using declarations such as

	:- type list(T) --->	[] ; [T | list(T)].
	:- type maybe(T) --->	yes(T) ; no.

	They must also declare the type signatures of the predicates they
	define, for example

	:- pred append(list(T), list(T), list(T)).

	The compiler infers the types of all variables in the program.
	Type errors are reported at compile time.

     o  Mercury is a strongly moded language.  The programmer must
	declare the instantiation state of the arguments of predicates
	at the time of the call to the predicate and at the time of the
	success of the predicate.  Currently only a subset of the
	intended mode system is implemented.  This subset effectively
	requires arguments to be either fully input (ground at the time
	of call and at the time of success) or fully output (free at
	the time of call and ground at the time of success).

	A predicate may be usable in more than one mode.  For example,
	append is usually used in at least these two modes:

	:- mode append(in, in, out).
	:- mode append(out, out, in).

	If a predicate has only one mode, the mode information can be
	given in the predicate declaration.

	:- pred factorial(int::in, int::out).

	The compiler will infer the mode of each call, unification and
	other builtin in the program.  It will reorder the bodies of
	clauses as necessary to find a left to right execution order;
	if it cannot do so, it rejects the program.  Like type-checking,
	this means that a large class of errors are detected at
	compile time.

     o  Mercury has a strong determinism system.  For each mode of each
	predicate, the programmer should declare whether the predicate
	will succeed exactly once (det), at most once (semidet), at
	least once (multi) or an arbitrary number of times (nondet).
	These declarations are attached to mode declarations like
	this:

	:- mode append(in, in, out) is det.
	:- mode append(out, out, in) is multi.

	:- pred factorial(int::in, int::out) is det.

	The compiler will try to prove the programmer's determinism
	declaration using a simple, predictable set of rules that seems
	sufficient in practice (the problem in general is undecidable).
	If it cannot do so, it rejects the program.

	As with types and modes, determinism checking catches many
	program errors at compile time.  It is particularly useful if
	some deterministic (det) predicates each have a clause for each
	function symbol in the type of one of their input arguments,
	and this type changes; you will get determinism errors for all
	of these predicates, telling you to put in code to cover the
	case when the input argument is bound to the newly added
	function symbol.

     o  Mercury has a module system.  Programs consist of one or more
	modules.  Each module has an interface section that contains
	the declarations for the types and predicates exported from the
	module, and an implementation section that contains the
	definitions of the exported entities and also definitions for
	types and predicates that are local to the module.  A type
	whose name is exported but whose definition is not, can be
	manipulated only by predicates in the defining module; this is
	how Mercury implements abstract data types.  For predicates
	that are not exported, Mercury supports automatic determinism
	inference.

     o  Mercury supports higher-order programming,
	with closures, currying, and lambda expressions.

     o  Mercury is very efficient (in comparison with existing logic
	programming languages).  Strong types, modes, and determinism
	provide the compiler with the information it needs to generate
	very efficient code.

The Mercury compiler is written in Mercury itself.  It was bootstrapped
using NU-Prolog and SICStus Prolog.  This was possible because after
stripping away the declarations of a Mercury program, the syntax of the
remaining part of the program is mostly compatible with Prolog syntax.

The Mercury compiler compiles Mercury programs to C, which it uses as a
portable assembler.  The system can exploit some GNU C extensions to the
C language, if they are available: the ability to declare global
register variables, the ability to take the addresses of labels, and
the ability to use inline assembler.  Using these extensions, it
generates code that is significantly better than all previous Prolog
systems known to us.  However, the system does not need these
extensions, and will work in their absence.

The current Mercury system runs on Unix machines.  It is known to run on
Solaris 2.x, IRIX 5.x, Ultrix 4.3, OSF/1.1, BSDI 1.1, and Linux.  It
should run without too many changes on other Unix variants as well.  If
you do encounter any problems, please check our WWW page at
<http://www.cs.mu.oz.au/~zs/mercury.html> to see if the bug has been
encountered already; if not, send us mail at <mercury-bugs@cs.mu.oz.au>.

The current source distribution uses gcc as the compiler.  We require gcc
version 2.6.3 or higher.  You will also need GNU make version 3.69 or higher.

The Mercury distribution contains:

     o  an autoconfiguration script
     o  the Mercury source for the compiler
     o  the Mercury source for the standard library
     o  the automatically generated C source for the compiler
        and the standard library
     o  the runtime system (written in C)
     o  Hans Boehm's conservative garbage collector for C
     o  a profiler
     o  some utility programs, including a make front-end for Mercury
	with automatic dependency recomputation
     o  the Mercury language reference manual
     o  the Mercury library reference manual
     o  the Mercury user's guide
     o  the Mercury frequently asked questions list
     o  the Prolog to Mercury transition guide
     o  some sample Mercury programs

The Mercury distribution is available via anonymous ftp or WWW
from the following locations:

	Australia:
		ftp://turiel.cs.mu.oz.au/pub/mercury
		http://www.cs.mu.oz.au/~fjh/mercury
	USA:
		ftp://ftp.cs.sunysb.edu/pub/XSB/mercury
	Europe:
		ftp://ftp.csd.uu.se/pub/Mercury

The home page of the project on the Web is
<http://www.cs.mu.oz.au/~zs/mercury.html>.

Fergus Henderson	<fjh@cs.mu.oz.au> 
Thomas Conway		<conway@cs.mu.oz.au> 
Zoltan Somogyi		<zs@cs.mu.oz.au> 

Department of Computer Science, University of Melbourne, Australia