[m-rev.] diff: update NEWS and HISTORY files for 10.04 release
Julien Fischer
juliensf at csse.unimelb.edu.au
Tue Jun 1 00:30:41 AEST 2010
Branches: main, 10.04
Announce that we support 64-bit Mac OS X in the NEWS file.
Shift the 0.13.X news into the HISTORY file.
NEWS:
Announce support for 64-bit Mac OS X.
Make some indentation consistent.
Fix a spelling error.
Delete the news entries for the 0.13 releases.
HISTORY:
Add the news entries for the 0.13 releases.
Julien.
Index: NEWS
===================================================================
RCS file: /home/mercury/mercury1/repository/mercury/NEWS,v
retrieving revision 1.522
diff -u -r1.522 NEWS
--- NEWS 31 May 2010 03:36:02 -0000 1.522
+++ NEWS 31 May 2010 14:24:54 -0000
@@ -62,7 +62,7 @@
* A new module, parsing_utils, has been added to provide support for
implementing recursive descent parsers.
-* The string.to_int familiy of predicates now fails (or throws an exception
+* The string.to_int family of predicates now fails (or throws an exception
for the det_ versions) on base 10 numbers that do not fit in the range
[int.min_int+1, int.max_int]. Numbers outside this range lead to overflow.
Numbers not in base 10 are assumed to denote bit patterns and are not
@@ -127,15 +127,15 @@
a process would terminate as soon as the original thread finished.
* The following predicate has been added to the set module:
- set.filter_map/3
+ set.filter_map/3
* The following predicates have been added to the array modules:
- array.fold/4
- array.foldl2/6
- version_array.foldl/4
+ array.fold/4
+ array.foldl2/6
+ version_array.foldl/4
* The following predicates have been added to the list module:
- list.filter_map_foldl/5
+ list.filter_map_foldl/5
list.map_corresponding/4
list.map2_foldl3/10
list.map_corresponding_foldl/6
@@ -369,6 +369,9 @@
* The width of error message lines can be adjusted with a new option,
`--max-error-line-width'.
+* Generation of 64-bit code on Mac OS X is now supported,
+ i.e. the x86_64*apple*darwin* architecture is now supported.
+
Changes to the Mercury deep profiler:
* The deep profiler now supports measuring a proxy for time: a counter that
@@ -630,370 +633,5 @@
* mdb now ignores lines beginning with a `#' character
in sourced files. This is useful for commenting mdb scripts.
-NEWS for Mercury 0.13.1
------------------------
-
-This release is primarily a bug-fix release.
-The problems fixed include:
-
-* polymorphic insts and mode-specific clauses did not work together.
-* polymorphic insts and export pragmas did not work together.
-* the compiler was not correctly enforcing the restriction that type
- variables in instance declarations should be distinct.
-* the compiler sometimes performed superclass reduction incorrectly,
- causing it to reject valid typeclass constraints.
-* installation of static archives on Mac OS X using mmc --make now
- works correctly. Previously, static archives caused linking problems
- because the table of contents was not being updated after installation.
-* non-exported typeclasses sometimes resulted in incomplete interface
- files being generated.
-
-In addition to the above bug-fixes we have the following addition to the
-standard library.
-
-Changes to the Mercury standard library:
-* We have added a new module `rtree', that provides region trees.
- These are a standard data structure for querying spatial information.
-
-
-
-NEWS for Mercury 0.13
----------------------
-
-HIGHLIGHTS
-==========
-
-Changes to the Mercury language:
-* The Mercury typeclass system now supports functional dependencies.
-* A new language construct allows programmers to promise that any given
- goal is pure or semipure.
-* Two new language constructs allow programmers to promise that all solutions
- of a given goal are equivalent with respect to the relevant equality
- theories.
-* We now have support for optional module initialisation and finalisation.
-* We now have support for module-local mutable variables.
-* We now have support for recognizing switches in which multiple switch arms
- have shared code.
-* A new pragma allows programmers to promise that in a predicate or function
- defined by mode-specific clauses, the mode-specific definitions have
- equivalent semantics.
-* We now allow users to control how each argument of a `pragma memo' predicate
- is tabled.
-* Support for the old-style lambda, mode and pragma syntax has been removed.
-* ':' is now the type qualification operator, not a module qualifier.
-* To ensure soundness, goals in negated contexts using non-local variables
- with dynamic modes (inst "any") must now be marked as impure.
-
-Changes to the Mercury standard library:
-* We have removed the predicates dealing with runtime type information (RTTI)
- from std_util.m. Any users impacted by this change should look for required
- functionality in the construct, deconstruct and type_desc modules of the
- standard library, in forms that have been mostly unchanged since the
- 0.11 release. In most cases, the differences are quite minor, but provide
- more expressive power.
-* We have moved the all-solutions predicates from std_util.m into a new
- library module, solutions.m. These predicates are still available in
- std_util.m but these versions are now deprecated.
-* We have moved the univ type, and related predicates, from std_util.m
- into a new library module, univ.m.
-* We have moved the maybe type, and related predicates, from std_util.m
- into a new library module, maybe.m.
-* We have moved the pair type, and related predicates, from std_util.m
- into a new library module, pair.m.
-* We have moved the unit type from std_util.m into a new library module,
- unit.m.
-* We have made the predicates semidet_succeed/0, semidet_fail/0 and
- cc_multi_equal/2 into builtins. Formerly these were exported by std_util.m.
-* We have added an `injection' module, for reversible maps that are injective.
-
-Changes to the Mercury compiler:
-* The compiler now generates error messages for mismatches between format
- strings and lists of values to be printed in calls to string.format and
- io.format.
-* The compiler now generates better error messages for determinism errors
- involving single-solution contexts.
-* We have significantly improved the compiler's performance on predicates
- with many clauses.
-* We have deleted the old --split-c-files option, as it conflicted with the
- implementation of module initialisation and finalisation.
-
-Portability Improvements:
-* We've ported Mercury to the x86_64 (AMD64 / Intel EMT64) architecture.
-* We've made the implementation compatible with gcc 4.1.
-
-Changes to the Mercury debugger:
-* Users can now see a listing of the source code lines referred to by the
- current environment (see the documentation for the `list' command in
- the Mercury Users' Guide).
-* Users can now keep hold of a term, referring to it even when execution has
- left the goal at which the term was available as the value of a program
- variable.
-* Users can now see the set of places where two terms differ from each other.
-* The `set' command has been replaced by several other commands: the `format',
- `format_param', `list_context_lines', `list_path', `xml_browser_cmd',
- `xml_tmp_filename', `fail_trace_counts', `pass_trace_counts' and
- `max_io_actions' commands.
-* The `save_to_file' command has been renamed the `dump' command.
-* The `save' command now saves the entire persistent state of the debugger
- (with one small exception that cannot be reestablished by an mdb command from
- an arbitrary point of execution).
-* The declarative debugger now supports an `undo' command, and allows users to
- select the search algorithm.
-* The declarative debugger can now exploit information from the "code
- footprints" of passed and failed test cases to find bugs with fewer
- questions. We have also added two tools, mslice and mdice, to manipulate
- files containing such footprints. See the "Trace counts" section of the
- Mercury User's Guide for details.
-* Subterm dependency tracking in the declarative debugger is now significantly
- faster.
-
-Changes to the compiler backends:
-* We have implemented an optimization, --optimize-constructor-last-call,
- that can turn recursive calls that are followed only by unifications that
- construct output arguments into tail calls. This can reduce the stack space
- requirements of the predicates to which it is applicable from linear
- in the size of the input data to constant.
-* We have implemented an optimization, --tuple, that can replace several
- arguments that are usually passed to predicates together with a single
- tuple. This can reduce parameter passing overheads.
-* The compiler can now optimize away the trail manipulation code from parts
- of the program that cannot affect the trail.
-* The compiler now optimizes away any instructions referring to values of dummy
- types. A type is a dummy type if it has one function symbol of arity zero.
-* Higher order calls are now cheaper on the low level C backend.
-
-Changes to the extras distribution:
-* We've added a library of data structures designed to work with solver types.
-* We've added a library to generate Windows installer packages.
-* We've added a program to generate optimisation flags for the compiler.
-
-
-DETAILED LISTING
-================
-
-Changes to the Mercury language:
-
-* We have added support for functional dependencies to the typeclass system.
- See the "Type classes" section of the Mercury Language Reference Manual for
- details.
-
-* A new language construct allows programmers to promise that any given
- goal is pure or semipure. Given Goal, a goal that uses impure and/or
- semipure code, the goal
-
- promise_pure ( Goal )
-
- promises that Goal presents a pure interface. Given Goal, a goal that
- uses impure code, the goal
-
- promise_semipure ( Goal )
-
- promises that Goal presents a semipure interface.
-
-* A new language construct allows programmers to promise that all solutions
- of a given goal are equivalent with respect to the relevant equality
- theories. Given Goal, a goal that computes values for two variables,
- X and Y, the goal
-
- promise_equivalent_solutions [X, Y] ( Goal )
-
- promises that all solutions of Goal are equivalent with respect to the
- equality theories of the types of X and Y. This means that the
- promise_equivalent_solutions goal will be det if Goal is cc_multi,
- and that the promise_equivalent_solutions goal will be semidet if Goal
- is cc_nondet.
-
- A related language construct allows programmers to promise that although
- the solutions of a given goal are not necessarily equivalent with respect
- to the relevant equality theories, it is nevertheless immaterial which one
- is chosen in a particular context. The language construct is the `arbitrary'
- goal, and the context is established by a `promise_equivalent_solution_sets'
- goal. Consider a type representing maps from keys to values which is
- implemented using 2-3 trees. In such a type, the precise shape of the tree
- doesn't matter; two trees should be considered equal if they contain the same
- set of keys and map them to the same values:
-
- :- type tree23(K, V)
- ---> two(tree23(K, V), K, V, tree23(K, V)
- ; three(tree23(K, K, V, tree23(K, V), K, V, tree23(K, V))
- where equality is tree23_equal
- and comparison is tree23_compare.
-
- Two values of e.g. type tree23(int, string) may differ in their top level
- function symbol even through they denote the same map. Deconstructing a
- value of such a type may therefore theoretically yield either "two" or
- "three" as the top level function symbol, although in practice which one
- you get is determined by the concrete structure of the term. Unifications
- of such values with specific function symbols are therefore permitted only
- in committed choice contexts. Unfortunately, one cannot simply put the
- deconstruction into the scope of a promise_equivalent_solutions goal,
- since the solutions are not equivalent in all contexts. However, the
- solutions will be equivalent in *some* contexts. Consider this function
- to count the number of key-value pairs in the map:
-
- count(Tree) = Count :-
- promise_equivalent_solution_sets [Count] (
- (
- arbitrary [Tree1, Tree2] (
- Tree = two(Tree1, _Key, _Value, Tree2)
- ),
- Count = 1 + count(Tree1) + count(Tree2)
- ;
- arbitrary [Tree1, Tree2, Tree3] (
- Tree = three(Tree1, _Key1, _Value1, Tree2,
- _Key2, _Value2, Tree3)
- ),
- Count = 2 + count(Tree1) + count(Tree2) + count(Tree3)
- )
- ).
-
- The construct `arbitrary [Tree1, Tree2] Goal', where Goal computes Tree1
- and Tree2, tells the compiler that it is OK to commit to the first solution
- of Goal, because regardless of whether the goal succeeds and if so with
- which values of Tree1 and Tree2, the set of solutions of the surrounding
- `promise_equivalent_solution_sets [Count] Goal' will not be affected.
- Regardless of whether Tree is bound to "two" or "three", the body of count
- will compute the right value for Count.
-
- A goal of the form `arbitrary [Vars] Goal' will be det if Goal is cc_multi,
- and it will be semidet if Goal is cc_nondet. Goals of that form may occur
- only inside `promise_equivalent_solution_sets' goals. There is no restriction
- on the determinism of `promise_equivalent_solution_sets' goals.
-
-* We have added support for optional module initialisation. See the
- "Module initialisation" section of the Mercury Language Reference
- Manual for details.
-
-* We have added support for optional module finalisation. See the
- "Module finalisation" section of the Mercury Language Reference
- Manual for details.
-
-* We have added support for module-local mutable variables.
- See the "Module-local mutable variables" section of the Mercury Language
- Reference Manual for details.
-
-* We now have support for recognizing switches in which multiple switch arms
- have shared code. Where previously programmers had to write code like this
-
- (
- X = a,
- ... code for a ...
- ;
- X = b(...),
- ... code for b ...
- ;
- X = c,
- ... code for c ...
- ... shared code ...
- ;
- X = d(...),
- ... code for d ...
- ... shared code ...
- )
-
- to have the disjunction recognized as a switch on X, they can now write
- code like this:
-
- (
- X = a,
- ... code for a ...
- ;
- X = b(...),
- ... code for b ...
- ;
- (
- X = c,
- ... code for c ...
- ;
- X = d(...),
- ... code for d ...
- ),
- ... shared code ...
- )
-
-* If a predicate or function is defined by mode-specific clauses, like this:
-
- reversible_sort(Raw::in, Sorted::out) :-
- list.sort(Raw, Sorted).
- reversible_sort(Raw::out, Sorted::in) :-
- is_sorted(Sorted),
- list.perm(Sorted, Raw).
-
- the compiler by default assumes that the definitions of the different modes
- have different semantics. Programmers can tell the compiler that the
- mode-specific definitions, though syntactically distinct, are semantically
- equivalent by including a pragma:
-
- :- pragma promise_equivalent_clauses(reverse_sort/2).
-
-* To ensure soundness, goals in negated contexts using non-local variables
- with dynamic modes (inst "any") must now be marked as impure.
-
- If a goal uses a variable with a dynamic mode (inst "any"),
- and that goal occurs inside a negated context (such as the
- condition of an if-then-else, or a lambda expression),
- and the variable also occurs outside of that negated context,
- then the compiler will infer that goal to be impure,
- and so such goals must normally be marked as "impure".
-
- This change was required because Mercury implements negation using
- the standard negation-as-failure approach, which is not sound if the
- negated goal binds any non-local variables.
-
- As usual, the programmer can use "promise_pure" if they are
- sure that the goal is in fact pure, e.g. because they know that
- the goal inside the negation will not instantiate the variable.
-
-Changes to the Mercury standard library:
-
-* We have added the function `divide_equivalence_classes' to the `eqvclass'
- module.
-
-* We have added an `injection' module, for reversible maps that are injective.
-
-* We have added list.foldl_corresponding/5, list.foldl2_corresponding/7,
- list.map2_foldl2/8 and list.det_split_list/4.
-
-* We have added string.word_wrap/2.
-
-* We have added set.fold4/10.
-
-* We have added semidet_true/0 and semidet_false/0 as synonyms for
- semidet_succeed/0 and semidet_fail/0.
-
-* We have added impure_true/0 and semipure_true/0.
-
-Changes to the Mercury compiler:
-
-* The compiler now generates error messages for known mismatches between format
- strings and lists of values to be printed in calls to string.format and
- io.format, unless the user specifies the --no-warn-known-bad-format-call
- option.
-
- If the user specifies the --warn-unknown-format-call option, the compiler
- will also generate error messages for calls to string.format and io.format
- in which the format string or the structure of the list of values to be
- printed are not statically available.
-
-Changes to the extras distribution:
-
-* We've added a library of data structures designed to work for solver types.
-
- The module extras/solver_types contains versions of the standard
- library's array, assoc_list, list and map modules that are designed to
- work with terms that have inst `any'.
-
-* We've added a library to generate Windows installer packages.
-
- The directory extras/windows_installer_generator contains a library to
- generate Wix source files. WiX is an XML language that is used to generate
- Microsoft Windows Installer (.msi) packages.
-
-* We've added a program to generate optimisation flags for the compiler.
-
- The directory extras/gator contains a program to search for the
- optimal set of compiler flags for a given program. The search
- algorithm used is a genetic algorithm, which can run in parallel over
- multiple hosts (by default, 1).
For news about earlier versions, see the HISTORY file.
Index: HISTORY
===================================================================
RCS file: /home/mercury/mercury1/repository/mercury/HISTORY,v
retrieving revision 1.30
diff -u -r1.30 HISTORY
--- HISTORY 18 Dec 2006 13:00:07 -0000 1.30
+++ HISTORY 31 May 2010 14:17:32 -0000
@@ -2906,10 +2906,367 @@
Mercury 0.13.0, 14 September 2006
---------------------------------
+HIGHLIGHTS
+==========
+
+Changes to the Mercury language:
+* The Mercury typeclass system now supports functional dependencies.
+* A new language construct allows programmers to promise that any given
+ goal is pure or semipure.
+* Two new language constructs allow programmers to promise that all solutions
+ of a given goal are equivalent with respect to the relevant equality
+ theories.
+* We now have support for optional module initialisation and finalisation.
+* We now have support for module-local mutable variables.
+* We now have support for recognizing switches in which multiple switch arms
+ have shared code.
+* A new pragma allows programmers to promise that in a predicate or function
+ defined by mode-specific clauses, the mode-specific definitions have
+ equivalent semantics.
+* We now allow users to control how each argument of a `pragma memo' predicate
+ is tabled.
+* Support for the old-style lambda, mode and pragma syntax has been removed.
+* ':' is now the type qualification operator, not a module qualifier.
+* To ensure soundness, goals in negated contexts using non-local variables
+ with dynamic modes (inst "any") must now be marked as impure.
+
+Changes to the Mercury standard library:
+* We have removed the predicates dealing with runtime type information (RTTI)
+ from std_util.m. Any users impacted by this change should look for required
+ functionality in the construct, deconstruct and type_desc modules of the
+ standard library, in forms that have been mostly unchanged since the
+ 0.11 release. In most cases, the differences are quite minor, but provide
+ more expressive power.
+* We have moved the all-solutions predicates from std_util.m into a new
+ library module, solutions.m. These predicates are still available in
+ std_util.m but these versions are now deprecated.
+* We have moved the univ type, and related predicates, from std_util.m
+ into a new library module, univ.m.
+* We have moved the maybe type, and related predicates, from std_util.m
+ into a new library module, maybe.m.
+* We have moved the pair type, and related predicates, from std_util.m
+ into a new library module, pair.m.
+* We have moved the unit type from std_util.m into a new library module,
+ unit.m.
+* We have made the predicates semidet_succeed/0, semidet_fail/0 and
+ cc_multi_equal/2 into builtins. Formerly these were exported by std_util.m.
+* We have added an `injection' module, for reversible maps that are injective.
+
+Changes to the Mercury compiler:
+* The compiler now generates error messages for mismatches between format
+ strings and lists of values to be printed in calls to string.format and
+ io.format.
+* The compiler now generates better error messages for determinism errors
+ involving single-solution contexts.
+* We have significantly improved the compiler's performance on predicates
+ with many clauses.
+* We have deleted the old --split-c-files option, as it conflicted with the
+ implementation of module initialisation and finalisation.
+
+Portability Improvements:
+* We've ported Mercury to the x86_64 (AMD64 / Intel EMT64) architecture.
+* We've made the implementation compatible with gcc 4.1.
+
+Changes to the Mercury debugger:
+* Users can now see a listing of the source code lines referred to by the
+ current environment (see the documentation for the `list' command in
+ the Mercury Users' Guide).
+* Users can now keep hold of a term, referring to it even when execution has
+ left the goal at which the term was available as the value of a program
+ variable.
+* Users can now see the set of places where two terms differ from each other.
+* The `set' command has been replaced by several other commands: the `format',
+ `format_param', `list_context_lines', `list_path', `xml_browser_cmd',
+ `xml_tmp_filename', `fail_trace_counts', `pass_trace_counts' and
+ `max_io_actions' commands.
+* The `save_to_file' command has been renamed the `dump' command.
+* The `save' command now saves the entire persistent state of the debugger
+ (with one small exception that cannot be reestablished by an mdb command from
+ an arbitrary point of execution).
+* The declarative debugger now supports an `undo' command, and allows users to
+ select the search algorithm.
+* The declarative debugger can now exploit information from the "code
+ footprints" of passed and failed test cases to find bugs with fewer
+ questions. We have also added two tools, mslice and mdice, to manipulate
+ files containing such footprints. See the "Trace counts" section of the
+ Mercury User's Guide for details.
+* Subterm dependency tracking in the declarative debugger is now significantly
+ faster.
+
+Changes to the compiler backends:
+* We have implemented an optimization, --optimize-constructor-last-call,
+ that can turn recursive calls that are followed only by unifications that
+ construct output arguments into tail calls. This can reduce the stack space
+ requirements of the predicates to which it is applicable from linear
+ in the size of the input data to constant.
+* We have implemented an optimization, --tuple, that can replace several
+ arguments that are usually passed to predicates together with a single
+ tuple. This can reduce parameter passing overheads.
+* The compiler can now optimize away the trail manipulation code from parts
+ of the program that cannot affect the trail.
+* The compiler now optimizes away any instructions referring to values of dummy
+ types. A type is a dummy type if it has one function symbol of arity zero.
+* Higher order calls are now cheaper on the low level C backend.
+
+Changes to the extras distribution:
+* We've added a library of data structures designed to work with solver types.
+* We've added a library to generate Windows installer packages.
+* We've added a program to generate optimisation flags for the compiler.
+
+
+DETAILED LISTING
+================
+
+Changes to the Mercury language:
+
+* We have added support for functional dependencies to the typeclass system.
+ See the "Type classes" section of the Mercury Language Reference Manual for
+ details.
+
+* A new language construct allows programmers to promise that any given
+ goal is pure or semipure. Given Goal, a goal that uses impure and/or
+ semipure code, the goal
+
+ promise_pure ( Goal )
+
+ promises that Goal presents a pure interface. Given Goal, a goal that
+ uses impure code, the goal
+
+ promise_semipure ( Goal )
+
+ promises that Goal presents a semipure interface.
+
+* A new language construct allows programmers to promise that all solutions
+ of a given goal are equivalent with respect to the relevant equality
+ theories. Given Goal, a goal that computes values for two variables,
+ X and Y, the goal
+
+ promise_equivalent_solutions [X, Y] ( Goal )
+
+ promises that all solutions of Goal are equivalent with respect to the
+ equality theories of the types of X and Y. This means that the
+ promise_equivalent_solutions goal will be det if Goal is cc_multi,
+ and that the promise_equivalent_solutions goal will be semidet if Goal
+ is cc_nondet.
+
+ A related language construct allows programmers to promise that although
+ the solutions of a given goal are not necessarily equivalent with respect
+ to the relevant equality theories, it is nevertheless immaterial which one
+ is chosen in a particular context. The language construct is the `arbitrary'
+ goal, and the context is established by a `promise_equivalent_solution_sets'
+ goal. Consider a type representing maps from keys to values which is
+ implemented using 2-3 trees. In such a type, the precise shape of the tree
+ doesn't matter; two trees should be considered equal if they contain the same
+ set of keys and map them to the same values:
+
+ :- type tree23(K, V)
+ ---> two(tree23(K, V), K, V, tree23(K, V)
+ ; three(tree23(K, K, V, tree23(K, V), K, V, tree23(K, V))
+ where equality is tree23_equal
+ and comparison is tree23_compare.
+
+ Two values of e.g. type tree23(int, string) may differ in their top level
+ function symbol even through they denote the same map. Deconstructing a
+ value of such a type may therefore theoretically yield either "two" or
+ "three" as the top level function symbol, although in practice which one
+ you get is determined by the concrete structure of the term. Unifications
+ of such values with specific function symbols are therefore permitted only
+ in committed choice contexts. Unfortunately, one cannot simply put the
+ deconstruction into the scope of a promise_equivalent_solutions goal,
+ since the solutions are not equivalent in all contexts. However, the
+ solutions will be equivalent in *some* contexts. Consider this function
+ to count the number of key-value pairs in the map:
+
+ count(Tree) = Count :-
+ promise_equivalent_solution_sets [Count] (
+ (
+ arbitrary [Tree1, Tree2] (
+ Tree = two(Tree1, _Key, _Value, Tree2)
+ ),
+ Count = 1 + count(Tree1) + count(Tree2)
+ ;
+ arbitrary [Tree1, Tree2, Tree3] (
+ Tree = three(Tree1, _Key1, _Value1, Tree2,
+ _Key2, _Value2, Tree3)
+ ),
+ Count = 2 + count(Tree1) + count(Tree2) + count(Tree3)
+ )
+ ).
+
+ The construct `arbitrary [Tree1, Tree2] Goal', where Goal computes Tree1
+ and Tree2, tells the compiler that it is OK to commit to the first solution
+ of Goal, because regardless of whether the goal succeeds and if so with
+ which values of Tree1 and Tree2, the set of solutions of the surrounding
+ `promise_equivalent_solution_sets [Count] Goal' will not be affected.
+ Regardless of whether Tree is bound to "two" or "three", the body of count
+ will compute the right value for Count.
+
+ A goal of the form `arbitrary [Vars] Goal' will be det if Goal is cc_multi,
+ and it will be semidet if Goal is cc_nondet. Goals of that form may occur
+ only inside `promise_equivalent_solution_sets' goals. There is no restriction
+ on the determinism of `promise_equivalent_solution_sets' goals.
+
+* We have added support for optional module initialisation. See the
+ "Module initialisation" section of the Mercury Language Reference
+ Manual for details.
+
+* We have added support for optional module finalisation. See the
+ "Module finalisation" section of the Mercury Language Reference
+ Manual for details.
+
+* We have added support for module-local mutable variables.
+ See the "Module-local mutable variables" section of the Mercury Language
+ Reference Manual for details.
+
+* We now have support for recognizing switches in which multiple switch arms
+ have shared code. Where previously programmers had to write code like this
+
+ (
+ X = a,
+ ... code for a ...
+ ;
+ X = b(...),
+ ... code for b ...
+ ;
+ X = c,
+ ... code for c ...
+ ... shared code ...
+ ;
+ X = d(...),
+ ... code for d ...
+ ... shared code ...
+ )
+
+ to have the disjunction recognized as a switch on X, they can now write
+ code like this:
+
+ (
+ X = a,
+ ... code for a ...
+ ;
+ X = b(...),
+ ... code for b ...
+ ;
+ (
+ X = c,
+ ... code for c ...
+ ;
+ X = d(...),
+ ... code for d ...
+ ),
+ ... shared code ...
+ )
+
+* If a predicate or function is defined by mode-specific clauses, like this:
+
+ reversible_sort(Raw::in, Sorted::out) :-
+ list.sort(Raw, Sorted).
+ reversible_sort(Raw::out, Sorted::in) :-
+ is_sorted(Sorted),
+ list.perm(Sorted, Raw).
+
+ the compiler by default assumes that the definitions of the different modes
+ have different semantics. Programmers can tell the compiler that the
+ mode-specific definitions, though syntactically distinct, are semantically
+ equivalent by including a pragma:
+
+ :- pragma promise_equivalent_clauses(reverse_sort/2).
+
+* To ensure soundness, goals in negated contexts using non-local variables
+ with dynamic modes (inst "any") must now be marked as impure.
+
+ If a goal uses a variable with a dynamic mode (inst "any"),
+ and that goal occurs inside a negated context (such as the
+ condition of an if-then-else, or a lambda expression),
+ and the variable also occurs outside of that negated context,
+ then the compiler will infer that goal to be impure,
+ and so such goals must normally be marked as "impure".
+
+ This change was required because Mercury implements negation using
+ the standard negation-as-failure approach, which is not sound if the
+ negated goal binds any non-local variables.
+
+ As usual, the programmer can use "promise_pure" if they are
+ sure that the goal is in fact pure, e.g. because they know that
+ the goal inside the negation will not instantiate the variable.
+
+Changes to the Mercury standard library:
+
+* We have added the function `divide_equivalence_classes' to the `eqvclass'
+ module.
+
+* We have added an `injection' module, for reversible maps that are injective.
+
+* We have added list.foldl_corresponding/5, list.foldl2_corresponding/7,
+ list.map2_foldl2/8 and list.det_split_list/4.
+
+* We have added string.word_wrap/2.
+
+* We have added set.fold4/10.
+
+* We have added semidet_true/0 and semidet_false/0 as synonyms for
+ semidet_succeed/0 and semidet_fail/0.
+
+* We have added impure_true/0 and semipure_true/0.
+
+Changes to the Mercury compiler:
+
+* The compiler now generates error messages for known mismatches between format
+ strings and lists of values to be printed in calls to string.format and
+ io.format, unless the user specifies the --no-warn-known-bad-format-call
+ option.
+
+ If the user specifies the --warn-unknown-format-call option, the compiler
+ will also generate error messages for calls to string.format and io.format
+ in which the format string or the structure of the list of values to be
+ printed are not statically available.
+
+Changes to the extras distribution:
+
+* We've added a library of data structures designed to work for solver types.
+
+ The module extras/solver_types contains versions of the standard
+ library's array, assoc_list, list and map modules that are designed to
+ work with terms that have inst `any'.
+
+* We've added a library to generate Windows installer packages.
+
+ The directory extras/windows_installer_generator contains a library to
+ generate Wix source files. WiX is an XML language that is used to generate
+ Microsoft Windows Installer (.msi) packages.
+
+* We've added a program to generate optimisation flags for the compiler.
+
+ The directory extras/gator contains a program to search for the
+ optimal set of compiler flags for a given program. The search
+ algorithm used is a genetic algorithm, which can run in parallel over
+ multiple hosts (by default, 1).
+
+
Mercury 0.13.1, 1 December 2006
-------------------------------
-See the NEWS file.
+This release is primarily a bug-fix release.
+The problems fixed include:
+
+* polymorphic insts and mode-specific clauses did not work together.
+* polymorphic insts and export pragmas did not work together.
+* the compiler was not correctly enforcing the restriction that type
+ variables in instance declarations should be distinct.
+* the compiler sometimes performed superclass reduction incorrectly,
+ causing it to reject valid typeclass constraints.
+* installation of static archives on Mac OS X using mmc --make now
+ works correctly. Previously, static archives caused linking problems
+ because the table of contents was not being updated after installation.
+* non-exported typeclasses sometimes resulted in incomplete interface
+ files being generated.
+
+In addition to the above bug-fixes we have the following addition to the
+standard library.
+
+Changes to the Mercury standard library:
+* We have added a new module `rtree', that provides region trees.
+ These are a standard data structure for querying spatial information.
.NET CLR back-end history
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to: mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions: mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------
More information about the reviews
mailing list