-
Notifications
You must be signed in to change notification settings - Fork 54
/
RELEASE_NOTES
226 lines (185 loc) · 9.49 KB
/
RELEASE_NOTES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
We are pleased to announce the release of version 0.10 of the Mercury system.
Mercury is a new general-purpose programming language, 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 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.
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 current Mercury system has been tested extensively on Solaris 2.x,
OSF/1.1, and Linux, and has in the past been known to run on IRIX 5.x,
Ultrix 4.3, BSDI 1.1, AIX, and HPUX; it should run without too many
changes on other Unix variants as well. It also runs on Windows 95
and Windows NT, using the Cygwin library. If you do encounter any
problems, please report them to <mercury-bugs@cs.mu.oz.au> (see the
BUGS file).
We recommend that you use gcc as the C compiler, preferably gcc
version 2.95.2 or later. If you're using gcc, you will need at least
version 2.7.2 or higher, except on Solaris, where you need version
2.95 or higher. You will also need GNU make version 3.69 or higher.
The Mercury distribution is split into three parts.
The "mercury-compiler" 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 debugger
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-extras" distribution contains some extra libraries for:
o lazy evaluation
o dynamic linking
o backtrackable (trailed) destructive update
o concurrency
o arithmetic
- arithmetic on complex and imaginary numbers
- a CLP(R) interface, i.e. constraint solving over real numbers
o a set of generic stream type classes
o UIs:
- graphics using Tk and OpenGL
- text interfaces using curses
- processing HTML forms using the CGI interface
o interfacing:
- XML parsing
- POSIX interface
- an ODBC database interface
and
o the Morphine trace analysis system
o two (!) curses bindings, one more complete than the other
o a general purpose lexer
o Moose, a parser generator for Mercury.
The "mercury-tests" distribution contains a test suite.
The three components of the Mercury distribution are available
via anonymous ftp or WWW from the following locations:
Australia:
ftp://ftp.mercury.cs.mu.oz.au/pub/mercury
We hope to be able to make it available at the following sites
too, eventually:
Sunsite and mirrors: (mercury-compiler source distribution only)
ftp://sunsite.unc.edu/pub/Linux/Incoming
ftp://sunsite.unc.edu/pub/linux/devel/lang/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/mercury/>.
--
The Mercury Team <http://www.cs.mu.oz.au/mercury/people.html>
Department of Computer Science and Software Engineering
The University of Melbourne, Australia