mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-08 10:23:03 +00:00
215 lines
9.9 KiB
Plaintext
215 lines
9.9 KiB
Plaintext
|
|
We are pleased to announce the release of version 20.06 of the Mercury system.
|
|
|
|
Mercury is a modern general-purpose programming language, originally
|
|
designed and implemented by a small group of researchers at the University
|
|
of Melbourne, Australia. Mercury is based on the paradigm of purely
|
|
declarative programming, and was designed to be useful for the
|
|
development of large and robust ``real-world'' applications.
|
|
It improves on existing logic programming languages by providing
|
|
increased productivity, reliability and efficiency, and by avoiding the
|
|
need for non-logical program constructs. Mercury provides the
|
|
traditional logic programming syntax, but also allows the
|
|
syntactic convenience of user-defined functions, smoothly integrating
|
|
logic and functional programming into a single paradigm.
|
|
|
|
For a list of what's new in this release, see the NEWS file.
|
|
|
|
The main features of Mercury are:
|
|
|
|
o Mercury is purely declarative: predicates and functions
|
|
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 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.
|
|
|
|
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 and
|
|
functions 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, functions 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 and functions that are not exported, Mercury
|
|
supports automatic type, mode, and 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 originally
|
|
bootstrapped using NU-Prolog and SICStus Prolog. This was possible
|
|
because if you stick to an appropriate subset of Mercury, then
|
|
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 Mercury compiler can also compile Mercury programs to Java, C# or
|
|
Erlang. See README.Java, README.CSharp, and README.Erlang respectively
|
|
for further details.
|
|
|
|
The current Mercury system has been tested on Linux (x86, x86_64, arm),
|
|
macOS (x86_64), Windows 7 and Windows 10 (x86 and x86_64),
|
|
FreeBSD (x86_64), OpenBSD (x86_64) and AIX.
|
|
|
|
In the past Mercury has also been known to run on: Digital Unix,
|
|
OSF1, IRIX 5.x, Ultrix 4.3, BSDI 1.1, HPUX, Linux (Alpha),
|
|
Compaq Tru64 Unix (Alpha), Solaris 2.7 (SPARC), Solaris (9),
|
|
Mac OS X (PowerPC) and Windows 95, 98, ME, NT, 2000 and XP.
|
|
|
|
It should run without too many changes on other Unix variants as well.
|
|
If you do encounter any problems, please report them to us via the
|
|
Mercury bug tracking system at <http://bugs.mercurylang.org>
|
|
(see the BUGS file).
|
|
|
|
We recommend that you use gcc as the C compiler, preferably gcc version 3.4 or
|
|
later. Do not use gcc versions 2.96, 3.0 or 4.0; those versions have bugs that
|
|
cause trouble for Mercury. If you are using gcc, you will need at least
|
|
version 2.95 or higher, except on Mac OS X where you will need version 3.3 or
|
|
higher. Visual C++ or clang may also be used as a C compiler.
|
|
(See README.MS-VisualC and README.clang for further details.)
|
|
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 an integrated procedural and declarative debugger
|
|
o some profilers
|
|
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
|
|
o dynamic linking
|
|
o backtrackable (trailed) destructive update
|
|
o arithmetic
|
|
- arithmetic on complex and imaginary numbers
|
|
- arithmetic on fixed-point numbers
|
|
o UIs:
|
|
- graphics using Tk, OpenGL, GLUT, GLFW, Xlib, Allegro or Cairo.
|
|
- text interfaces using curses
|
|
- processing HTML forms using the CGI interface
|
|
o interfacing:
|
|
- XML parsing
|
|
- POSIX interface
|
|
- an ODBC database interface
|
|
o the Morphine trace analysis system
|
|
o a general purpose lexer
|
|
o Moose, a parser generator for Mercury.
|
|
|
|
The Mercury distribution is available via WWW from the following locations:
|
|
|
|
Australia:
|
|
<http://dl.mercurylang.org/index.html>
|
|
|
|
The home page of the project on the Web is:
|
|
|
|
<http://www.mercurylang.org>.
|
|
|
|
--
|
|
The Mercury Team <http://www.mercurylang.org/development/people.html>
|