[mercury-users] Am I nuts to try Mercury for this?

[Fergus Henderson]

On 21-May-1998, tcklnbrg <at at ingenuity-sw.com> wrote:
> But, I do have several concerns surrounding Mercury:
> 
> ???
> 
> Is Mercury just another lab project that is going to die when the
> current funding or current mentor disappears?

No, I'm pretty sure it won't.

In particular, Zoltan Somogyi (my PhD supervisor and co-founder of the
Mercury project) started work on designing a better logic programming
language way back in the early 80s, when he was doing his PhD thesis.
The language he designed then ("Ptah") was never implemented, but it
was one of the major influences in the design of Mercury; for Zoltan,
Mercury thus represents the realization and the continuation of a
long-standing research effort.  I'm sure that Zoltan is in it for the
long haul.  Zoltan has tenure, I believe, and is still several decades
away from retirement ;-)  I'm sure Zoltan will continue to work on the
Mercury system for a long time to come.  Zoltan has been very
successful in attracting good graduate students to the Mercury project
and I'm sure he will continue with that.  So even if all of the current
crop of graduate students move on to other things (which I think is
unlikely) the Mercury group will not evaporate.

Melbourne Uni's computer science department has for a long time had a
particular expertise in logic programming, with current academic staff
such as (in no particular order) Lee Naish, Harald Sondergaard, Leon
Sterling, Peter Stucky, and Rao Kotagiri continuing this.  It's a
very enjoyable department to work in.  Currently there is a large group
of great people who are fun to be around working on the Mercury
project.  This sort of atmosphere encourages others.  We have recently
had two postgrad students from European universities spend some time
here with the Mercury group doing projects related to Mercury, and
there are another two planning to come later this year.
So currently the Mercury group here at Melbourne Uni is certainly
still in an expansion phase.  In fact the difficulty has been finding
office space for everyone!  So things are looking rosy, at least for
the near future.

In addition, Mercury is being used as the basis of other new projects
such as the ARGO project and the HAL project.  The ARGO project is a
joint venture between four universities and two companies in Europe
which has been granted major funding from the ECRC.  The project
is based around Mercury, with aims that include gaining experience
with the use of Mercury, and exploiting the benefits of Mercury in
a commercial environment.

The HAL project is a joint venture between some people at the University
of Melbourne (Peter Stuckey) and Monash University (Kim Marriot,
Maria Garcia-de-la-Banda, and Warwick Harvey).  They are building a
system called HAL which is designed for solving constraint problems;
their HAL implementation will generate Mercury code.

Another point is that the Mercury implementation is free software, licensed
under the GPL (and LGPL).  This encourages the Mercury user community
to extend and improve the Mercury implementation and to
to contribute their changes back to the community.
For example, the original version of Mercury's ODBC interface was
contributed by Mission Critical Software Inc.
But as well as these benefits, the fact that Mercury is free software
provides an important security for those considering using Mercury.
If something goes wrong, or if there is a need to port Mercury to a
new system, etc., then it is always possible (and it will always remain
possible) for users to fix the problem themselves, or to hire their own
contracters to fix it.  Thus the worst-case scenario is much less
worrying than it would be for proprietry software.


So to summarize, I think there are a lot of good reasons why
Mercury will be alive and kicking for a long time yet ;-)

> How stabile is Mercury right now?  If I build and deploy a big rule-base
> in it will it crash all over the place?

The current implementation is quite stable.  We have a large test suite
(nearly 200,000 lines of code in total, including more than 20,000
lines of specific test cases, plus other code including the Mercury
compiler itelf) which we run on a nightly basis on several architectures.
So no, it won't crash all over the place.

Of course, the very latest features such as type classes and tabling
have not been tested nearly as well as the rest.  If you write code
in a novel style, or if you make use of the very latest features,
then you may occaisionally run into bugs.  However, these are usually
pretty easy to fix.  We tend to be very responsive to bug reports.
Users are important to our research, so we try to keep them ;-).

(And even if you do happen to run across a bug, the symptom is much more
likely to be that the compiler refuses to compile something or gets
an internal error during compilation than that it generates incorrect
code, so typically it's not that difficult to work around.)

> Is there any support in the Prolog community for transitioning to
> Mercury or a successor?

Maybe you should ask that one in comp.lang.prolog ;-)

> Interoperability with other languages, ie. Java?  Right now, I will have
> to use pipes or files, I suppose, but Java is CORBA-enabled.  Can
> Mercury be CORBA-enabled? or Might there be another way to link Mercury
> and Java?

I haven't tried it myself, but you should be able to link Mercury and
Java using Mercury's C interface and Java's native code interface.
Mercury has a pretty good C interface.  I've used it to link with C,
C++, and Fortran.

> At this point my use for Mercury is for code development purposes, not
> end-user apps.  But, one of these days, I want a rule-based system that
> can be embedded into Java apps.  Is the Mercury team thinking of making
> a Mercury-In-Java? What about a Mercury to Java compiler (ie,  Paul
> Tarau's "Jinni", in late beta )?  

Currently the Mercury compiler has an option to generate bytecode, and
Bert Thompson is working on a bytecode interpreter, written in C, for
this bytecode.  If/when this is finished, I suppose it would be possible
to port the bytecode interpreter to Java, thus giving you a Mercury-in-Java.
This would however be a non-trivial exercise, and the end result would
probably not run very fast.

A Java backend for the Mercury compiler looks much more attractive.
We have thought about this, and I have some ideas about how to do it,
but as yet we have not found the time to do it.  (This would make
a great Masters thesis, if anyone out there is interested or has
some students who might be interested...)

> Also, I like having the command-line type interpreter for testing new
> snippets of code---SWI's is nice.  Any way to do something similar with
> Mercury, currently?

The latest development version of Mercury (available via our ftp site)
includes a 4-port style debugger.  You can't load new code
interactively, and you can't type in queries at the debugger
prompt -- instead you need write a small test module and compile/link
that.  But you can debug things interactively.

The work being done on the bytecode interpreter is being done with the
aim of eventually supporting things interactive queries.  However,
progress on the bytecode interpreter has been slow, so I'm not sure how
far we'll get on that.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.