beta-release

[Fergus Henderson]

Hi,

I'm planning on announcing a new beta-release to the
mercury-announce mailing list.

Any comments and/or objections?

P.S.  What is the current status of the ODBC interface and
termination analysis?

--------------------------------------------------

NEWS since Mercury release 0.7
------------------------------

* We've added support for constraint handling.

  The new library package `cfloat_lib', in the extras/clpr directory,
  is a Mercury interface to the CLP(R) constraint solver.  The module
  `cfloat' defines a type `cfloat' for constrained floating point numbers,
  together with the usual arithmetic operators (+, -, *, /, <, >, =<, >=)
  as well as some non-linear constraint functions (abs, min, max,
  sin, cos, arcsin, and arccos).  The module `dump' provides I/O predicates
  for printing out constraints.

  Note that since `cfloat' is a different type than `float', you
  have to use the `==' operator provided in this package rather
  than `=' if you want to unify a cfloat with a float.
  
  To support constraint handling, we've made the mode system a bit
  more flexible.  There is a new inst `any' for variables whose value
  is unknown but which may have constraints on them. 

  The support for `any' insts is not quite complete; in particular, we
  do not support passing values of inst `free' where values of inst
  `any' are expected, so sometimes you have to explicitly initialize
  variables by calling cfloat__init/1.

  Also we don't yet support any equivalent to SICStus Prolog's
  call_residue/3 or the three-argument version of CLP(R)'s dump predicate.

  But apart from that, it all works nicely.  And even though we support
  equivalents to such nasty non-logical meta-programming constructs
  as CLPR's `dump' primitive, we still manage to preserve referential
  transparency -- the interface provided is a completely pure declarative
  interface.

* We've added some support for Prolog-style variables and coroutining

  The module extras/trailed_updated/var.m provides a type `var(T)'
  which is a Prolog-style variable that holds a value of type T.
  These variables can have the new inst `any' described above.
  There's also an implementation of freeze/2, for coroutining
  (dynamic scheduling).  The samples subdirectory has an example
  of the use of freeze/2 to solve the N-queens problem.

* We now provide generalized trailing support.

  There is a new set of grades `*.tr' (e.g. `asm_fast.gc.tr') which
  provide support for trailing.  This could be used by predicates or
  functions defined using the C interface to perform such things as
  constraint solving, backtrackable destructive update, or even automatic
  unwinding of database transactions on backtracking.  See the
  documentation in the "Trailing" section of the Mercury language
  reference manual (it's at the end of the "C interface" section,
  which is in the chapter on "Pragmas").

* We've rewritten the `store' module to use unique modes.

  The `store' module provides mutable variables.

* We've added library modules for backtrackable destructive update.

  See the new modules `tr_array' and `tr_store' in the extras/trailed_update.
  These are versions of `array' and `store' that use trailed backtrackable
  destructive update.

* The library predicate unsorted_aggregate/4 in std_util.m
  now interleaves calls of the aggregation predicate with
  the generation of solutions, rather than first finding all
  solutions and then aggregating them.  This allows you
  to print out solutions as they are found, for example.

* We've improved the C interface.

  We now handle the case when `main' is defined in C rather than in Mercury
  slightly more cleanly -- there are functions mercury_init()
  and mercury_terminate() for initializing and terminating the
  Mercury runtime.  See runtime/init.h for documentation of the functions,
  and see samples/c_interface/simpler_c_calls_mercury for an example of
  their use.

* We now support user-defined equality predicates.

  See the Mercury language reference manual for details.

  However, until we have support for type classes (coming soon :-),
  you will probably run into trouble if you try to use compare/3,
  write/1, functor/2, etc., on a type with user-defined equality.
  Hence we recommend that this feature should not yet be used.
  Because of this, we haven't bothered to document the
  rationale or use for user-defined equality predicates
  (though rest assured that when we do have type classes,
  this feature will indeed be useful).

* We have added support for dynamic link libraries (DLLs) on Windows.

  XXX This is not yet enabled by default, though, because it has not
  yet been tested.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.