[m-rev.] for review: update NEWS and HISTORY files

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Mar 8 01:18:03 AEDT 2002


Estimated hours taken: 0.5
Branches: main

NEWS:
	Add a "Highlights" section at the top.
	Improve the wording in a couple of places.
	Move the news about changes to the debugger into a separate section.

NEWS:
HISTORY:
	Move the news for 0.10.1 and 0.10 to the HISTORY file.

Workspace: /home/ceres/fjh/mercury
Index: HISTORY
===================================================================
RCS file: /home/mercury1/repository/mercury/HISTORY,v
retrieving revision 1.17
diff -u -d -r1.17 HISTORY
--- HISTORY	28 Feb 2001 13:09:01 -0000	1.17
+++ HISTORY	7 Mar 2002 13:55:40 -0000
@@ -1506,3 +1506,351 @@
 higher level C code than original back-end.  The first prototype
 compiled "hello world" in September 1999.  The compiler successfully
 compiled itself using the MLDS back-end on 12 May 2000.
+
+
+Mercury 0.10.1, April 3rd, 2001
+-------------------------------
+
+This is mainly a bug-fix release.
+
+There are however some new packages in the mercury-extras distribution:
+* lex: a lexical analyzer library for Mercury.
+* curs: a simplified binding to the ncurses/panel libraries for terminal I/O.
+
+
+Mercury 0.10, February 25th, 2001
+---------------------------------
+
+HIGHLIGHTS
+
+Changes to the Mercury language:
+* We've added support for explicit type qualification.
+* We've added support for tuples.
+* We've added support for record syntax.
+* Type class methods can now be defined by listing the clauses
+  directly in the instance declaration.
+* The syntax for defining insts and modes has been changed.
+  The old syntax is still accepted but is deprecated.
+
+Changes to the Mercury standard library:
+* We've added several new standard library modules:
+  - `pprint', for pretty printing.
+  - `counter', for managing counters.
+  - `enum', a typeclass for types which can be converted to and from integers.
+  - `sparse_bitset', an abstract data type for storing sparse sets of integers
+     or enumerations.
+  - `bitmap', an abstract data type for storing sets of integers.
+  - `hash_table', an generic hash table implementation
+* The `store' module now makes use of existential types.
+
+Changes to the Mercury implementation:
+* We've implemented a new back-end for the Mercury compiler.
+  This features improved compilation speed, offers better portability,
+  and sometimes generates substantially better code.
+  (The original back-end is still included.)
+* There's a version of the new back-end which generates code
+  for Microsoft's new .NET system.
+* There's a version of the new back-end which compiles directly
+  to assembler, using the GCC back-end.
+* Various improvements to `mtags'.
+
+Additional packages in the mercury-extras distribution:
+* Moose: a parser generator for Mercury.
+* concurrency: support for multi-threading/concurrency.
+* stream: an implementation of generic I/O streams, using type classes.
+* xml: a library for parsing XML.
+
+DETAILED LISTING
+
+Changes to the Mercury language:
+
+* We've added support for explicit type qualification.
+
+  An expression of the form "Term `with_type` Type",
+  e.g. "X `with_type` list(int)", can be used in place of
+  the specified Term to constrain the type of that term.
+  This is sometimes useful for resolving type ambiguities,
+  which can occur as a result of overloading or polymorphism.
+
+  See the "Explicit type qualification" and "Variable scoping"
+  sections of the language reference manual for details.
+
+* We've added support for tuple types, similar to those in most
+  other functional languages. Tuples use the syntax `{A, B, ...}'.
+  See the "Builtin types" section of the "Types" chapter of the
+  Mercury Language Reference Manual for details.
+
+* We've added support for record syntax, so that fields of
+  constructors can be conveniently extracted and updated
+  without writing lots of trivial access predicates.
+  See the "Field access functions" section of the "Types" chapter
+  of the Mercury Language Reference Manual for details.
+
+  Note that the syntax has changed slightly since the version
+  that appeared in the release of the day in early January 2000.
+  `Value =^ field' is now the syntax for DCG field selection,
+  rather than `Value := ^ field'. Field update functions are
+  named 'field :=' rather than 'field:='. We also allow field
+  access functions to take extra arguments.
+
+* The behaviour of the Mercury parser (parser__read_term) applied
+  to terms with functor `{}/N' has been changed. The parser from
+  Mercury 0.9 parsed "{1, 2, 3}" as `{}(','(1, ','(2, 3)))'.
+  It is now parsed as `{}(1, 2, 3)'.
+
+* The operator `^' is now used for record syntax, and cannot be
+  used for user-defined functions or constructors.
+
+* You can now declare functions by giving a determinism but without
+  supplying the modes.  The default function modes will be assumed.
+  This is particularly useful for partial functions.
+  For example:
+  	GetEvens = list__filter_map(
+		(func(X) = X is semidet :- X mod 2 = 0)).
+
+* We've generalized the higher-order term syntax a little:
+  in `Foo(Args)', we now allow Foo to be any term, not just
+  a variable.
+
+* The syntax for defining insts and modes has been changed to be
+  more uniform.  For example, the old syntax
+
+  	:- inst myfree = free.
+  	:- mode out :: myfree -> ground.
+
+  would now be written
+
+  	:- inst myfree == free.
+  	:- mode out == myfree >> ground.
+
+  The old syntax is still accepted but is deprecated.  Support for it may
+  eventually be dropped.
+
+* Type class methods can now be defined by listing the clauses
+  directly in the instance declaration.  You no longer need to define a
+  separate predicate or function for each type class method definition.
+
+Changes to the standard library:
+
+* We've added some new library predicates: assoc_list__keys_and_values,
+  list__map2, list__map3, map__foldl2, tree234__foldl2, relation__traverse,
+  std_util__aggregate2, and builtin__promise_only_solution_io.
+
+* We've added function versions of std_util__solutions,
+  std_util__solutions_set, std_util__aggregate, map__search,
+  map__insert and map__update.
+
+* We've added functions to allow record syntax to be used
+  with some of the types in the standard library:
+	array__elem/2, 'array__elem :='/3,
+	bt_array__elem/2, 'bt_array__elem :='/3,
+	map__elem/2, 'map__elem :='/3,
+	map__det_elem/2, 'map__det_elem :='/3.
+
+* We've added a pretty printing module, `pprint', to the standard library.
+
+* We've added a new function to the Mercury standard library:
+	std_util__construct_tuple/1.
+
+* Functions `int:^/2' and `integer:^/2' have been removed.
+  Use `int__xor/2' and `integer__xor/2' instead.
+  The operator `^' is now used for record syntax.
+
+* We've added reverse modes for `int__xor'.
+
+* There is a new predicate `random__permutation', for
+  computing a random permutation of a list.
+
+* There is a new library module `counter' for managing counters.
+
+* We've added a new library module `sparse_bitset', which implements
+  an abstract data type for storing sets of integers or enumerations.
+
+* There is a new library module `enum' which contains a typeclass
+  describing types which can be converted to and from integers.
+
+* Four new parametric instantiations `maybe/1', `maybe_error/1',
+  `pair/2' and `pair/1' have been added to the `std_util' library
+  module.  These make it more convenient to work with non-ground
+  terms of the corresponding type.
+
+* The `store' module now makes use of existential types.
+
+  The `store__init/1' predicate and the `store__some_store_type' type
+  are now deprecated; the new existentially typed predicate
+  `store__new/1' should be used instead.
+
+* We've reimplemented the `string__format/3' procedure.
+
+  The new implementation is a lot more efficient and fixes several
+  bugs in the old implementation.  The new implementation also
+  eliminates some subtle differences in behaviour between
+  string__format and the standard ANSI/ISO C printf() function:
+
+	- For the old string__format, the default precision was 15
+	  (i.e. the number of significant figures in an IEEE double
+	  precision float), but for ISO C's printf(), the default
+	  precision is 6.
+
+	- For the old string__format, for the e, E, f, F, g and G conversions,
+	  the "precision" field in the format always specified the
+	  number of significant figures, but for ISO C's printf(), the
+	  precision only specifies as the number of significant
+	  figures for the g and G conversions, whereas for the e, E,
+	  f, and F conversions the precision specifies the number of
+	  digits after the decimal point.
+
+	- For the old string__format, floating point numbers were
+	  truncated to the specified precision, but for ISO C's
+	  printf(), they are rounded rather than being truncated.
+
+* We've added a new function, math__solve_quadratic/3.
+
+* We've changed the semantics of deconstruct/4, in light of the introduction
+  of existentially quantified types. Previously, if deconstruct/4 was given
+  a value of type `univ' it automagically unwrapped it and gave back the
+  functor, arity and arguments of the unwrapped value. This behaviour was
+  not documented, but made sense because there was no way to unwrap a
+  univ without knowing (or guessing) its type. Now that univ is defined
+  as a normal (existentially quantified) type, this behaviour is unnecessary,
+  and a wart besides, so has been removed. If you have a univ and you want
+  to get the unwrapped value's functor, arity and arguments, then you can
+  call "univ_value(Univ)" to extract the value before calling deconstruct.
+  (Doing that also works in Mercury 0.9 and Mercury 0.10.)
+
+* We've added func versions of the remaining preds in int.m that
+  did not already have them.
+
+* We've added a new `bitmap' library module.
+
+* We've added std_util__dynamic_cast/2 for type-safe runtime dynamic
+  type casting for ground types.
+
+* We've extended the array module with array__sort/1, array__foldl/3 and
+  array__foldr/3.
+
+* We've added a new `hash_table' library module.
+
+Changes to the Mercury implementation:
+
+* We've implemented a new back-end for the Mercury compiler.
+
+  The new back-end, which is enabled by using the `--high-level-code'
+  (or `-H') option or the `hlc.gc' grade, generates much higher-level
+  C code that does not require the use of GNU C extensions such as
+  global register variables or non-local gotos.  It is also simpler
+  and more portable than the old back-end.
+
+  The main drawback of the new back-end is that for tail calls it only
+  optimizes direct tail recursion; loops written using tail calls
+  between two or more mutually recursive procedures are not guaranteed
+  to use constant stack space.
+
+  Preliminary benchmarking suggests that compilation speed is probably
+  about 20% better with the new back-end, and the generated executables
+  are likely to be smaller (though this will depend on the platform,
+  optimization options, etc.).  Speed of the generated code varies:
+  sometimes it is better than the old back-end, sometimes it is worse.
+  There are a few optimizations that we have not yet implemented for
+  the new back-end that might make a significant difference for some
+  applications.  But there are also some optimizations which we have
+  implemented for the new back-end that have not been implemented for
+  the old back-end.  We encourage those for whom performance is
+  important to try their application with both the old and new
+  back-ends and compare for themselves.
+
+  The new back-end is not yet quite as mature or complete as the old back-end.
+  It does not yet support the following standard Mercury features:
+  	- abstractly exported equivalence types defined as `float'
+	- calling compare/3, or the `in = in' mode of unification,
+	  for certain standard library types (std_util__type_desc/0,
+	  and std_util__type_ctor_desc/0).
+	- calling copy/2 on higher-order terms
+  It also does not support the following implemention-specific
+  features that the old back-end supports:
+	- demangling of symbol names in the profiler
+	- fact tables for procedures with determinism `nondet' or `multi'
+  	- the Mercury debugger (mdb)
+  	- the Morphine trace analysis system
+	- the Aditi deductive database interface
+  	- the `--split-c-files' option
+  	- the `--introduce-accumulators' option
+	- dynamic linking (via the dl__mercury_sym procedure in
+	  extras/dynamic/dl.m in the mercury-extras distribution)
+	  for procedures with arguments of type `float' or `char'
+
+* There's a new back-end that targets .NET.
+
+  Thanks to Microsoft's generous and ongoing support, both financial
+  and otherwise, we've been able to port Mercury to Microsoft's new
+  .NET system.  There's another new back-end for the Mercury compiler,
+  based on the `--high-level-code' back-end, that compiles to IL, the
+  Microsoft .NET Intermediate Language.
+
+  This back-end is enabled using the new `--target il' option
+  (or just `--il' for short), or the `ilc' grade.
+
+  Compiler support for this new back-end is mostly complete,
+  but large parts of the standard library are still not yet
+  implemented for this new port.
+
+  This is still work in progress.
+
+  For more details, see the README.DotNet file, and
+  <http://www.cs.mu.oz.au/research/mercury/dotnet.html>.
+
+* Native code compiler.
+
+  There's a new back-end for the Mercury compiler that compiles
+  directly to assembler, rather than than going via C.  This
+  back-end is enabled using the new `--target asm' option.
+
+  This new back-end is implemented by linking the Mercury compiler
+  with the (relatively) language independent GNU Compiler Collection
+  back-end.  In other words, there is now a Mercury front-end for GCC.
+
+  Note that this should be considered as a beta release of the native
+  code compiler.  Furthermore our current version of the native code
+  compiler is based on an unreleased snapshot version of the GCC
+  back-end.
+
+  So far we have only tested it on i686-pc-linux-gnu (Intel x86-based
+  PCs running Linux).  But in theory it should work fine on other
+  platforms too.
+
+  For details see <http://www.cs.mu.oz.au/mercury/download/gcc-backend.html>.
+
+* The old back-end now generates faster code at low optimization levels.
+
+* The compiler is now a little bit faster.
+
+* The names of some of the `--enable-*' options to `configure' have changed.
+
+  See the output of `configure --help' for details.
+
+Changes to the development environment:
+
+* The debugger has been improved in several respects:
+
+  - It has some new forward movement commands:
+    * `next' steps over a call, like gdb's `next' command;
+    * `exception' skips forward until an exception is thrown.
+  - It can perform retry across I/O.
+  - It can now print parts of terms, and fields of terms can be
+    specified by field name as well as by position number.
+  - It has a more flexible mechanism for setting browsing parameters.
+  - It now handles ambiguous procedure specifications in "break"
+    commands gracefully.
+  - The state of the debugger can now be saved and restored, using the
+    `save' and `source' commands (respectively).
+
+  For details, see the documentation of the `next', `exception',
+  `break', `set', and `save' commands in the "Debugger commands" section
+  of the "Debugging" chapter of the Mercury User's Guide.  (The changes
+  to `retry' and `print' have unfortunately not been documented yet.)
+
+* Several improvements have been made to `mtags' to make it easier to
+  find predicate/function definitions and to improve support for
+  enhanced features of Vim.  The command-line options to `mtags' have
+  changed and Vim-style tags files are now output as the default (but
+  will work with Vi as well).  Do `mtags --help' for more information.
Index: NEWS
===================================================================
RCS file: /home/mercury1/repository/mercury/NEWS,v
retrieving revision 1.247
diff -u -d -r1.247 NEWS
--- NEWS	6 Mar 2002 14:34:52 -0000	1.247
+++ NEWS	7 Mar 2002 14:14:35 -0000
@@ -1,6 +1,31 @@
 NEWS since Mercury release 0.10.1:
 ----------------------------------
 
+HIGHLIGHTS
+==========
+
+Changes to the Mercury language:
+* Improved support for higher-order functions.
+* Support for defining predicates or functions
+  using different clauses for different modes.
+* Support for Haskell-like "@" expressions.
+
+Changes to the Mercury compiler:
+* A new `--smart-recompilation' option, for fine-grained dependency tracking.
+* A new optional warning: `--warn-non-tail-recursion'.
+* A new optimization: `--constraint-propagation'.
+
+Major improvements to the Mercury debugger, including:
+* Support for source-linked debugging using vim (rather than emacs).
+* Command-line completion.
+* Ability to display values of higher-order terms.
+
+Numerous minor improvements to the Mercury standard library.
+
+
+DETAILED LISTING
+================
+
 Changes to the Mercury language:
 
 * If a higher-order function term has inst 'ground' it is now assumed to have
@@ -8,9 +33,9 @@
   This makes higher-order functional programming much easier, particularly when
   passing functions to polymorphic predicates.
 
-  This change is not backwards compatible since, for safety, we must now
-  disallow calls that would cause a variable that has a nonstandard function
-  inst to become 'ground'.
+  This change is not completely backwards compatible since, for safety,
+  we must now disallow calls that would cause a variable that has a
+  nonstandard function inst to become 'ground'.
 
 * The constructor for lists is now called '[|]' rather than '.'.
   `./2' will eventually become the module qualification operator.
@@ -116,9 +141,9 @@
   `int__unchecked_rem/2' for which no checking is performed and the
   behaviour if the right operand is zero is undefined.
 
-* We've removed the buggy reverse modes of the arithmetic functions in
-  float.m and extras/complex_numbers (because of rounding errors the
-  functions aren't actually reversible).
+* We've removed the reverse modes of the arithmetic functions in
+  float.m and extras/complex_numbers.  (Because of rounding errors,
+  the functions aren't actually reversible.)
 
 * We've removed the destructive update modes of string__set_char,
   string__set_char_det and string__unsafe_set_char. The compiler
@@ -181,7 +206,7 @@
   way to support user-defined modes for the parser state and integrate
   better with lex.
 
-Changes to the Mercury implementation:
+Changes to the Mercury compiler:
 
 * The Mercury compiler can now perform smart recompilation, enabled by the
   `--smart-recompilation' option. With smart recompilation, when the
@@ -193,28 +218,6 @@
   causes the compiler to issue a warning about any directly recursive
   call that is not a tail call.
 
-* The debugger can now print goals just as Prolog debuggers do. At an exit
-  port of e.g. append, the command "print goal" will print the current goal
-  in a form such as "append([1], [2], [1, 2])".
-
-* You can now navigate terms in the debugger by argument name as well as by
-  argument number.
-
-* The debugger can now print higher order values.
-
-* The debugger can now perform command line completion when compiled
-  with GNU Readline support enabled.
-
-* We've added a 'view' command to `mdb', which opens a `vim' window and
-  in it displays the current source location, updated at each event.  This
-  requires X11 and a version of `vim' with the `clientserver' feature
-  enabled.
-
-* The `--window' mdb option now creates a window for mdb, not
-  the program.  The main advantage of the new behaviour is that
-  redirection of the program's input and output works.  The old
-  behaviour is still available with `mdb --program-in-window'.
-
 * We've fixed a long-standing bug in the handling of module imports.
   Previously, if `module1' imported `module2' which imported `module3' in
   its interface section, then any types, insts, modes and typeclasses defined
@@ -238,351 +241,28 @@
 * The `--convert-to-goedel' option has been removed.
   It never really worked anyway.
 
-NEWS for Mercury release 0.10.1:
---------------------------------
-
-This is mainly a bug-fix release.
-
-There are however some new packages in the mercury-extras distribution:
-* lex: a lexical analyzer library for Mercury.
-* curs: a simplified binding to the ncurses/panel libraries for terminal I/O.
-
-
-NEWS for Mercury release 0.10:
-------------------------------
-
-HIGHLIGHTS
-==========
-
-Changes to the Mercury language:
-* We've added support for explicit type qualification.
-* We've added support for tuples.
-* We've added support for record syntax.
-* Type class methods can now be defined by listing the clauses
-  directly in the instance declaration.
-* The syntax for defining insts and modes has been changed.
-  The old syntax is still accepted but is deprecated.
-
-Changes to the Mercury standard library:
-* We've added several new standard library modules:
-  - `pprint', for pretty printing.
-  - `counter', for managing counters.
-  - `enum', a typeclass for types which can be converted to and from integers.
-  - `sparse_bitset', an abstract data type for storing sparse sets of integers
-     or enumerations.
-  - `bitmap', an abstract data type for storing sets of integers.
-  - `hash_table', an generic hash table implementation
-* The `store' module now makes use of existential types.
-
-Changes to the Mercury implementation:
-* We've implemented a new back-end for the Mercury compiler.
-  This features improved compilation speed, offers better portability,
-  and sometimes generates substantially better code.
-  (The original back-end is still included.)
-* There's a version of the new back-end which generates code
-  for Microsoft's new .NET system.
-* There's a version of the new back-end which compiles directly
-  to assembler, using the GCC back-end.
-* Various improvements to `mtags'.
-
-Additional packages in the mercury-extras distribution:
-* Moose: a parser generator for Mercury.
-* concurrency: support for multi-threading/concurrency.
-* stream: an implementation of generic I/O streams, using type classes.
-* xml: a library for parsing XML.
-
-DETAILED LISTING
-================
-
-Changes to the Mercury language:
-
-* We've added support for explicit type qualification.
-
-  An expression of the form "Term `with_type` Type",
-  e.g. "X `with_type` list(int)", can be used in place of
-  the specified Term to constrain the type of that term.
-  This is sometimes useful for resolving type ambiguities,
-  which can occur as a result of overloading or polymorphism.
-
-  See the "Explicit type qualification" and "Variable scoping"
-  sections of the language reference manual for details.
-
-* We've added support for tuple types, similar to those in most
-  other functional languages. Tuples use the syntax `{A, B, ...}'.
-  See the "Builtin types" section of the "Types" chapter of the
-  Mercury Language Reference Manual for details.
-
-* We've added support for record syntax, so that fields of
-  constructors can be conveniently extracted and updated
-  without writing lots of trivial access predicates.
-  See the "Field access functions" section of the "Types" chapter
-  of the Mercury Language Reference Manual for details.
-
-  Note that the syntax has changed slightly since the version
-  that appeared in the release of the day in early January 2000.
-  `Value =^ field' is now the syntax for DCG field selection,
-  rather than `Value := ^ field'. Field update functions are
-  named 'field :=' rather than 'field:='. We also allow field
-  access functions to take extra arguments.
-
-* The behaviour of the Mercury parser (parser__read_term) applied
-  to terms with functor `{}/N' has been changed. The parser from
-  Mercury 0.9 parsed "{1, 2, 3}" as `{}(','(1, ','(2, 3)))'.
-  It is now parsed as `{}(1, 2, 3)'.
-
-* The operator `^' is now used for record syntax, and cannot be
-  used for user-defined functions or constructors.
-
-* You can now declare functions by giving a determinism but without
-  supplying the modes.  The default function modes will be assumed.
-  This is particularly useful for partial functions.
-  For example:
-  	GetEvens = list__filter_map(
-		(func(X) = X is semidet :- X mod 2 = 0)).
-
-* We've generalized the higher-order term syntax a little:
-  in `Foo(Args)', we now allow Foo to be any term, not just
-  a variable.
-
-* The syntax for defining insts and modes has been changed to be
-  more uniform.  For example, the old syntax
-
-  	:- inst myfree = free.
-  	:- mode out :: myfree -> ground.
-
-  would now be written
-
-  	:- inst myfree == free.
-  	:- mode out == myfree >> ground.
-
-  The old syntax is still accepted but is deprecated.  Support for it may
-  eventually be dropped.
-
-* Type class methods can now be defined by listing the clauses
-  directly in the instance declaration.  You no longer need to define a
-  separate predicate or function for each type class method definition.
-
-Changes to the standard library:
-
-* We've added some new library predicates: assoc_list__keys_and_values,
-  list__map2, list__map3, map__foldl2, tree234__foldl2, relation__traverse,
-  std_util__aggregate2, and builtin__promise_only_solution_io.
-
-* We've added function versions of std_util__solutions,
-  std_util__solutions_set, std_util__aggregate, map__search,
-  map__insert and map__update.
-
-* We've added functions to allow record syntax to be used
-  with some of the types in the standard library:
-	array__elem/2, 'array__elem :='/3,
-	bt_array__elem/2, 'bt_array__elem :='/3,
-	map__elem/2, 'map__elem :='/3,
-	map__det_elem/2, 'map__det_elem :='/3.
-
-* We've added a pretty printing module, `pprint', to the standard library.
-
-* We've added a new function to the Mercury standard library:
-	std_util__construct_tuple/1.
-
-* Functions `int:^/2' and `integer:^/2' have been removed.
-  Use `int__xor/2' and `integer__xor/2' instead.
-  The operator `^' is now used for record syntax.
-
-* We've added reverse modes for `int__xor'.
-
-* There is a new predicate `random__permutation', for
-  computing a random permutation of a list.
-
-* There is a new library module `counter' for managing counters.
-
-* We've added a new library module `sparse_bitset', which implements
-  an abstract data type for storing sets of integers or enumerations.
-
-* There is a new library module `enum' which contains a typeclass
-  describing types which can be converted to and from integers.
-
-* Four new parametric instantiations `maybe/1', `maybe_error/1',
-  `pair/2' and `pair/1' have been added to the `std_util' library
-  module.  These make it more convenient to work with non-ground
-  terms of the corresponding type.
-
-* The `store' module now makes use of existential types.
-
-  The `store__init/1' predicate and the `store__some_store_type' type
-  are now deprecated; the new existentially typed predicate
-  `store__new/1' should be used instead.
-
-* We've reimplemented the `string__format/3' procedure.
-
-  The new implementation is a lot more efficient and fixes several
-  bugs in the old implementation.  The new implementation also
-  eliminates some subtle differences in behaviour between
-  string__format and the standard ANSI/ISO C printf() function:
-
-	- For the old string__format, the default precision was 15
-	  (i.e. the number of significant figures in an IEEE double
-	  precision float), but for ISO C's printf(), the default
-	  precision is 6.
-
-	- For the old string__format, for the e, E, f, F, g and G conversions,
-	  the "precision" field in the format always specified the
-	  number of significant figures, but for ISO C's printf(), the
-	  precision only specifies as the number of significant
-	  figures for the g and G conversions, whereas for the e, E,
-	  f, and F conversions the precision specifies the number of
-	  digits after the decimal point.
-
-	- For the old string__format, floating point numbers were
-	  truncated to the specified precision, but for ISO C's
-	  printf(), they are rounded rather than being truncated.
-
-* We've added a new function, math__solve_quadratic/3.
-
-* We've changed the semantics of deconstruct/4, in light of the introduction
-  of existentially quantified types. Previously, if deconstruct/4 was given
-  a value of type `univ' it automagically unwrapped it and gave back the
-  functor, arity and arguments of the unwrapped value. This behaviour was
-  not documented, but made sense because there was no way to unwrap a
-  univ without knowing (or guessing) its type. Now that univ is defined
-  as a normal (existentially quantified) type, this behaviour is unnecessary,
-  and a wart besides, so has been removed. If you have a univ and you want
-  to get the unwrapped value's functor, arity and arguments, then you can
-  call "univ_value(Univ)" to extract the value before calling deconstruct.
-  (Doing that also works in Mercury 0.9 and Mercury 0.10.)
-
-* We've added func versions of the remaining preds in int.m that
-  did not already have them.
-
-* We've added a new `bitmap' library module.
-
-* We've added std_util__dynamic_cast/2 for type-safe runtime dynamic
-  type casting for ground types.
-
-* We've extended the array module with array__sort/1, array__foldl/3 and
-  array__foldr/3.
-
-* We've added a new `hash_table' library module.
-
-Changes to the Mercury implementation:
-
-* We've implemented a new back-end for the Mercury compiler.
-
-  The new back-end, which is enabled by using the `--high-level-code'
-  (or `-H') option or the `hlc.gc' grade, generates much higher-level
-  C code that does not require the use of GNU C extensions such as
-  global register variables or non-local gotos.  It is also simpler
-  and more portable than the old back-end.
-
-  The main drawback of the new back-end is that for tail calls it only
-  optimizes direct tail recursion; loops written using tail calls
-  between two or more mutually recursive procedures are not guaranteed
-  to use constant stack space.
-
-  Preliminary benchmarking suggests that compilation speed is probably
-  about 20% better with the new back-end, and the generated executables
-  are likely to be smaller (though this will depend on the platform,
-  optimization options, etc.).  Speed of the generated code varies:
-  sometimes it is better than the old back-end, sometimes it is worse.
-  There are a few optimizations that we have not yet implemented for
-  the new back-end that might make a significant difference for some
-  applications.  But there are also some optimizations which we have
-  implemented for the new back-end that have not been implemented for
-  the old back-end.  We encourage those for whom performance is
-  important to try their application with both the old and new
-  back-ends and compare for themselves.
-
-  The new back-end is not yet quite as mature or complete as the old back-end.
-  It does not yet support the following standard Mercury features:
-  	- abstractly exported equivalence types defined as `float'
-	- calling compare/3, or the `in = in' mode of unification,
-	  for certain standard library types (std_util__type_desc/0,
-	  and std_util__type_ctor_desc/0).
-	- calling copy/2 on higher-order terms
-  It also does not support the following implemention-specific
-  features that the old back-end supports:
-	- demangling of symbol names in the profiler
-	- fact tables for procedures with determinism `nondet' or `multi'
-  	- the Mercury debugger (mdb)
-  	- the Morphine trace analysis system
-	- the Aditi deductive database interface
-  	- the `--split-c-files' option
-  	- the `--introduce-accumulators' option
-	- dynamic linking (via the dl__mercury_sym procedure in
-	  extras/dynamic/dl.m in the mercury-extras distribution)
-	  for procedures with arguments of type `float' or `char'
-
-* There's a new back-end that targets .NET.
-
-  Thanks to Microsoft's generous and ongoing support, both financial
-  and otherwise, we've been able to port Mercury to Microsoft's new
-  .NET system.  There's another new back-end for the Mercury compiler,
-  based on the `--high-level-code' back-end, that compiles to IL, the
-  Microsoft .NET Intermediate Language.
-
-  This back-end is enabled using the new `--target il' option
-  (or just `--il' for short), or the `ilc' grade.
-
-  Compiler support for this new back-end is mostly complete,
-  but large parts of the standard library are still not yet
-  implemented for this new port.
-
-  This is still work in progress.
-
-  For more details, see the README.DotNet file, and
-  <http://www.cs.mu.oz.au/research/mercury/dotnet.html>.
-
-* Native code compiler.
-
-  There's a new back-end for the Mercury compiler that compiles
-  directly to assembler, rather than than going via C.  This
-  back-end is enabled using the new `--target asm' option.
-
-  This new back-end is implemented by linking the Mercury compiler
-  with the (relatively) language independent GNU Compiler Collection
-  back-end.  In other words, there is now a Mercury front-end for GCC.
-
-  Note that this should be considered as a beta release of the native
-  code compiler.  Furthermore our current version of the native code
-  compiler is based on an unreleased snapshot version of the GCC
-  back-end.
-
-  So far we have only tested it on i686-pc-linux-gnu (Intel x86-based
-  PCs running Linux).  But in theory it should work fine on other
-  platforms too.
-
-  For details see <http://www.cs.mu.oz.au/mercury/download/gcc-backend.html>.
-
-* The old back-end now generates faster code at low optimization levels.
-
-* The compiler is now a little bit faster.
+Changes to the Mercury debugger:
 
-* The names of some of the `--enable-*' options to `configure' have changed.
+* The debugger can now print goals just as Prolog debuggers do. At an exit
+  port of e.g. append, the command "print goal" will print the current goal
+  in a form such as "append([1], [2], [1, 2])".
 
-  See the output of `configure --help' for details.
+* You can now navigate terms in the debugger by argument name as well as by
+  argument number.
 
-Changes to the development environment:
+* The debugger can now print higher order values.
 
-* The debugger has been improved in several respects:
+* The debugger can now perform command line completion when compiled
+  with GNU Readline support enabled.
 
-  - It has some new forward movement commands:
-    * `next' steps over a call, like gdb's `next' command;
-    * `exception' skips forward until an exception is thrown.
-  - It can perform retry across I/O.
-  - It can now print parts of terms, and fields of terms can be
-    specified by field name as well as by position number.
-  - It has a more flexible mechanism for setting browsing parameters.
-  - It now handles ambiguous procedure specifications in "break"
-    commands gracefully.
-  - The state of the debugger can now be saved and restored, using the
-    `save' and `source' commands (respectively).
+* We've added a 'view' command to `mdb', which opens a `vim' window and
+  in it displays the current source location, updated at each event.  This
+  requires X11 and a version of `vim' with the `clientserver' feature
+  enabled.
 
-  For details, see the documentation of the `next', `exception',
-  `break', `set', and `save' commands in the "Debugger commands" section
-  of the "Debugging" chapter of the Mercury User's Guide.  (The changes
-  to `retry' and `print' have unfortunately not been documented yet.)
+* The `--window' mdb option now creates a window for mdb, not
+  the program.  The main advantage of the new behaviour is that
+  redirection of the program's input and output works.  The old
+  behaviour is still available with `mdb --program-in-window'.
 
-* Several improvements have been made to `mtags' to make it easier to
-  find predicate/function definitions and to improve support for
-  enhanced features of Vim.  The command-line options to `mtags' have
-  changed and Vim-style tags files are now output as the default (but
-  will work with Vi as well).  Do `mtags --help' for more information.
+For news about earlier versions, see the HISTORY file.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list