mercury/Documentation/NEWS_2001_02_25_release_0_10

Mercury 0.10, 25 February 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 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.


Mercury 0.10.1, 3 April 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.