Mercury

Appeared in Volume 8/2, May 1995

Keywords: mercury.

ok@goanna.cs.rmit.edu.au
Richard A. O'Keefe
13th February 1995

Last Friday I finally found some time to sit down with Zoltan Somogyi and

see the wonders of Mercury. In outline:

Prolog syntax;
sum-of-product types (similar to Hindley/Milner);
strong compile time mode checking (can express "single-threading");
predicates can be declared 'det' (must success exactly once) or 'semidet' may succeed at most once) or have many solutions like Prolog;
so Prolog-compatible that the 58000 line Mercury compiler can be compiled either by itself or by the NU Prolog compiler (which ignores some of the declarations);
no coroutining;
compiles to native code via GCC, can exploit GCC extensions, can also manage without them with some performance costs;
a well built system (or so it seems on a first glance);
awesome benchmark results!

I have to say that to me constraint logic programming seems like being more in the spirit of Prolog, in that CLP is even better at handling partial information and even less tied to left->right execution than vanilla Prolog. But I also have to say that if you are totally fed up with rewriting things in C to get enough speed, and if you're sick to death of C's pathetic type checking, Mercury may be exactly what you want. In particular, when Mercury is finished (it's finished enough to run many Prolog benchmarks, but floating point is not there yet, and while in-place update is planned, I don't believe it's installed yet) it may be exactly the language that Fernando Pereira would like for his finite state automaton stuff.

When I read Zoltan's thesis several years ago, I had no comment on it because his ideas seemed obviously right. Now that they're being turned into code, he's being proven right. I look forward to using Mercury.

zs@cs.mu.oz.au
Zoltan Somogyi
21st March 1995

Richard leaves out one of the most important points about Mercury, that it is a pure logic programming language. It has no cuts, no var, no ==, no assert/retract. Even I/O is declarative, based on the idea of unique modes, which are analogous to linear types in functional programming (the "single threading" Richard mentions). Apart from removing one more source of errors from programs, this declarativeness allows us to transform programs for optimization (e.g. propagating constraints, introducing accumulators, etc), to parallelize programs automatically, and to use declarative debugging. We have people working in all three of these directions. We are not working on coroutining as such because implementing coroutining requires most of the work required for parallelization but it yields a much smaller benefit, given that parallel machines are increasingly common. For example, all the CPU servers in our department are multiprocessors.

The declarativeness also means that Mercury is necessarily incompatible with Prolog. The Mercury compiler is executable either with a Prolog system (at present either NU-Prolog or SICStus Prolog) or with Mercury not because the languages are fully compatible, but because for bootstrapping the compiler is deliberately written in the intersection of Mercury and Prolog, with separate Mercury and Prolog implementations of I/O.

Two developments since Richard wrote his posting: Mercury successfully bootstrapped itself at the end of February, and Mercury now implements floating point numbers, although in the current implementation they are not as efficient as we would like. However, integers and operations on them have always been as fast as in C.

Further information on the Mercury project (including some papers on the system) are available through the World Wide Web at URL http://www.cs.mu.oz.au/~zs/mercury.html