New in release 0.13.1 of the Mercury distribution

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.

• We have added a new module `rtree', that provides region trees. These are a standard data structure for querying spatial information.

New in release 0.13 of the Mercury distribution

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.
• 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).