mercury/Documentation/NEWS_2006_09_14_release_0_13

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
-------------------------------

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.