[m-rev.] for post-commit review: update release notes for 13.05 release
Julien Fischer
jfischer at opturion.com
Wed Apr 24 15:43:33 AEST 2013
Update release notes for 13.05 release.
RELEASE_NOTES:
Mercury now works on 64-bit Windows.
Update email and web addresses for the project.
The distribution is no longer split into three parts.
Mention that we have a module for doing arithmetic on
fixed-point numbers.
Mention the GLFW binding.
The Mercury team are no longer at the University of
Melbourne. (And the CSSE departement no longer exists
by that name, anyway.)
Julien.
diff --git a/RELEASE_NOTES b/RELEASE_NOTES
index 5504ac2..69531b7 100644
--- a/RELEASE_NOTES
+++ b/RELEASE_NOTES
@@ -1,5 +1,5 @@
-We are pleased to announce the release of version 12.08 of the Mercury
system.
+We are pleased to announce the release of version 13.05 of the Mercury
system.
Mercury is a modern general-purpose programming language, designed and
implemented by a small group of researchers at the University of
@@ -18,112 +18,112 @@ 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.
+ 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
+ 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.
+ :- 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
+ They must also declare the type signatures of the predicates and
+ functions they define, for example
- :- pred append(list(T), list(T), list(T)).
+ :- 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.
+ 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).
+ 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:
+ 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).
+ :- 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.
+ If a predicate has only one mode, the mode information can be
+ given in the predicate declaration.
- :- pred factorial(int::in, int::out).
+ :- 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.
+ 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.
+ 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.
+ 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.
+ 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.
+ 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
@@ -144,8 +144,8 @@ 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), Linux (x86_64),
-Mac OS X (x86 and x86_64), and Windows (x86).
+The current Mercury system has been tested on Linux (x86 and x86_64),
+Mac OS X (x86 and x86_64), and Windows (x86 and x86_64).
For Windows, we have tested this release on Windows XP SP3, Windows 7,
and Windows Server 2008 R2.
@@ -156,17 +156,18 @@ Mac OS X (PowerPc) and Windows 95, 98, ME, NT and
2000.
It should run without too many changes on other Unix variants as well.
If you do encounter any problems, please report them to via the
-Mercury bug tracking system at <http://bugs.mercury.csse.unimelb.edu.au>
+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 version 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. You will also need GNU make version 3.69 or higher.
+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 is split into three parts.
-The "mercury-compiler" distribution contains:
+The Mercury distribution contains:
o an autoconfiguration script
o the Mercury source for the compiler
o the Mercury source for the standard library
@@ -177,45 +178,38 @@ The "mercury-compiler" distribution contains:
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
+ 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 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, Xlib, Allegro or Cairo.
+ - 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
-and
o the Morphine trace analysis system
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:
+The Mercury distribution is available via WWW from the following locations:
- Australia:
- ftp://ftp.mercury.csse.unimelb.edu.au/pub/mercury
+ Australia:
+ <http://dl.mercurylang.org/index.html>
The home page of the project on the Web is:
- <http://www.mercury.csse.unimelb.edu.au>.
+ <http://www.mercurylang.org>.
--
-The Mercury Team <http://www.csse.unimelb.edu.au/contact/people.html>
-Department of Computer Science and Software Engineering
-The University of Melbourne, Australia
+The Mercury Team <http://www.mercurylang.org/contact/people.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20130424/44922965/attachment.html>
More information about the reviews
mailing list