Mercury

[Fergus Henderson]

[I wrote the mail below before seeing Richard O'Keefe's reply
in this thread; I must say that I agree with Richard's reply,
indeed he states many of the things that I would have liked
to say, more clearly than I could do.

My mail to the Clean list is delayed because I have to send
it from my home machine rather than my work machine, because
the overly-sensitive spam detector on the Clean mailing list
autorejects my posts if I post from my main account, apparenty
due to the software (a) looking at the envelope from-address
rather than the "From:" header and (b) the software doing
a case-sensitive comparison.  For the mercury-users mailing
list, we have a similar process of rejecting mail from people
who are not subscribed to the list, but rejected mail is always
sent to a human moderator who can approve it anyway.  This
avoids false hits, which are reasonably common because people
often subscribe under one account and post from another.
The administrators of the Clean mailing list might want to
consider doing something similar.]

Alex wrote (via Antonio Eduardo Costa Pereira <costa@ufu.br>):
> I have a few questions about Mercury. It seems that you work in the
> Mercury team

That's correct.

> 1- It must be ported to the platform that almost everybody is
> using. [...] Mercury will not be widely
> used unless you people port it to _WINDOWS_.

We have in fact ported it to Windows.
A binary distribution of the latest release (Mercury 0.8.1)
for Windows is available from two sites via our WWW page
<http://www.cs.mu.oz.au/mercury/download/release.html>.

The current port uses Cygwin, a Unix emulation library for Windows.
Mission Critical (a Belgian software company) have also done some
work on porting Mercury to MSVC++.

> 2- If you don't make
> Mercury easy to install, very few people will show interest
> to your language.

We have indeed invested a very large amount of effort into
making Mercury easy to install.

On Linux systems, Mercury is now very easy to install, because we
provide packages in Debian and now also RedHat (RPM) format; good
Linux distributions such as SuSE Linux provide menu-driven installation
programs than can install packages in these formats with basically no
user intervention required.

On Windows, it is not quite as easy; you have to first install
Cygwin, then you have to unpack the binary distribution
(tar -zxf mercury*.tar.gz), and finally you have to type
`sh configure' and then `make install'.  But this is still
pretty straight-forward.

Currently, I think it is more important for us to do things
which will attract other developers of the kind that will
contribute libraries, tools, and so forth that will help us
to gather critical mass.  Given our limited resources, I think
we should at this stage aim for quality of users rather than
just quantity of users.  That means putting a bit more
effort into making things easy for Linux users than for
Windows users, since Linux users are part of the free software
community and are more likely to contribute stuff back to the
Mercury distribution.

Of course we'll continue to provide binary distributions for
Windows, I'm just saying that it's not worth our while to
devote most of our attention to Windows at this point in time.

> The guy should put the CD-ROM
> in his driver (under Windows 98, of course), close the door
> and wait for the installation to be complete. Then, he clicks
> a nice icon, and WHAW! A beautiful GUI, with components,
> menus, editors, databases, help, multimedia, etc.

Well, writing all that kind of stuff from scratch is a huge amount
of work.  I prefer to reuse that stuff.  There are of course a 
couple of GUIs called Emacs and XEmacs, and these already have
menus, editors, help, and support for source-linked debuggers,
source-linked compiler error messages, etc.  For those that
like IDEs, Mercury works reasonably well within Emacs;
Emacs can parse the error messages of the Mercury compiler,
Mercury supports Emacs tags files, and there is an Emacs
interface to the Mercury debugger which includes an (imperfect)
form of source linking.

> 3- The compiler must be so fast that it feels like an
> interpreter.

Well, my very latest development version of Mercury includes an
interactive query interface, which works by compiling the query
on-the-fly and then dynamically linking it into the process. 
This feels like an interpreter...  but not like a fast interpreter ;-)

> The generated code must be as efficient as Clean's.

I haven't run any benchmarks against Clean, but I suspect
that we probably pass this criteria in most circumstances.  
We don't have to worry about lazy evaluation, which makes
generating efficient code a lot easier.

> The compiler itself must fit in a floppy disk (Clean compiler
> fits in a floppy disk, with room for a few example and the
> unpack utility).

I don't think this is a relevant criterion anymore.
Pretty much no-one uses floppies for transporting programs
these days.  I don't think many people will reject
a program simply because it doesn't fit on a floppy disk.

> The small compiler makes easy to download
> the compiler.

This is a relevant point.  The current Mercury binary distribution
is about 13M.  But that distribution includes a compiler,
debugger, time profiler, memory profiler, support for
constraint solving, and so on.  Most of that size is in
the different copies of the standard libraries, compiled
with different options.

It might be worth us building a separate "Mercury-lite" distribution
for quicker downloads.  Of course, building and testing such distributions
all the different platforms that we need to support takes a lot of work...

> A question: I examined the syntax of a few programs written in
> Mercury. I noticed that there were declarations everywhere.
> Is this necessary?  Or do you have type inference?

We do have type (and mode, determinism, etc.) inference.
However, inference is not enabled by default -- you have
to use a compiler option (--infer-all) to enable it.
We find that explicit type, mode, and determinism
declarations lead to more readable programs.

Note that Mercury does require declarations for all entities which
are exported from a module -- you only get inference for entities which
are local to the module that they are defined in.  (The Haskell report
leaves this undefined.  What does Clean have to say about cross-module
type inference?)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.