[mercury-users] Any recent developments?

[Fergus Henderson]

On 13-Jul-1998, Ralph Becket <rwab1 at cam.sri.com> wrote:
> This has been a very quiet list of late.  Just wondering what the
> status of the Mercury project is at present.  What's currently on the
> to-do list and how close are things to completion?  Keen evangelists
> want to know!

Here's what Zoltan Somogyi <zs at cs.mu.OZ.AU> recently said in response to a
similar question from Luke Evans:

> > I'm following the development of Mercury with much interest.  However,
> > there have been no releases of the language recently which makes me
> > wonder whether interest in the project is waning, or if there are other
> > problems.  Are there plans to release a post 0.7.3 version soon?
> 
> Interest in the project is far from waning; we have more people working
> on the project than ever before. In fact, we have so many different projects
> going on that it is difficult to find a time when all aspects of the system
> are close to stable, so we can do a release.
> 
> Currently we plan to release Mercury 0.8 in September. The following NEWS
> file lists the things that will definitely be in the release (tabling
> a la XSB for the case without negation should also be on that list).
> Several other improvements that may or may not make it into the release:
> 
> 	support for existential types
> 	a polished interface to the debugger
> 	an accurate profiler that accumulates information about specific
> 		chains of call sites, not whole procedures
> 	a prototype native garbage collector
> 	compile time garbage collection
> 	tail recursion optimization modulo constructor application
> 	automatic accumulator introduction when recursive calls are followed
> 		only by an associative computation
> 	an improved termination analysis algorithm
> 
> Zoltan.

NEWS since release 0.7.3:
-------------------------

Changes to the Mercury language:
********************************

* The type system now includes support for Haskell-style type classes.

  Type classes let you specify an interface and then provide multiple
  different implementations of that interface.  They're similar to
  abstract base classes in C++ or "interfaces" in Java.
  See the "Type classes" chapter of the Mercury Language Reference Manual
  for details.

  Unlike Haskell 1.4, Mercury supports multi-parameter type classes,
  but we do not (yet) support constructor classes, and nor do we
  support default methods.

  The aim of this extension is twofold.  One aim is to provide more
  fine-grained encapsulation control: nested sub-modules within a
  single source file provide a convenient method for encapsulating
  units smaller than a source file.  The other aim is to provide better
  support for structuring large software packages that consist of many
  source files.  Sub-modules can be defined in separate files, with
  separate compilation, which means that you can also use this feature
  to combine a group of existing Mercury modules into a single logical
  package, with proper namespace control and encapsulation.

  See the "Modules" chapter of the Mercury language reference manual
  for details.

* We have made more improvements to the C interface.

  The C interface now includes support for defining procedures
  that can have multiple solutions (i.e. those whose determinism
  is `nondet' or `multi') in C.

  Also there's a new declaration, `pragma import', which is a bit
  like the existing `pragma c_code' declaration except that
  instead of giving a C code fragment, you just give the name
  of a C function.  `pragma import' is like the inverse of the
  existing `pragma export' declaration.

  XXX These features are not yet documented.
  XXX (See tests/hard_coded/pragma_import.m for some examples.)

* We have added tabling. XXX

* Mode inference can now infer "mostly-unique" modes as well as
  "unique" modes.

* You can now declare both committed-choice ("cc") and backtracking (non-cc)
  modes for the same predicate.
  
  Determinism analysis will pick the appropriate one to use for each
  call based on the context.

* The module system now includes support for sub-modules.

Changes to the Mercury standard library:
****************************************

* The getopt module now supports a new type of option data, namely
  `maybe_int(maybe(int))', to allow optional arguments with integer values.
  There is also a new corresponding lookup predicate,
  getopt__lookup_maybe_int_option/3. 

  See the "getopt" chapter of the Mercury Library Reference Manual for details.

* Support for memory profiling: new predicates report_full_memory_stats/0
  in benchmarking.m and io__report_full_memory_stats/2 in io.m.

  See the "benchmarking" chapter of the Mercury Library Reference Manual
  for details.

* Miscellaneous new predicates.

  The Mercury standard library now includes the following new predicates:
  bag__least_upper_bound/3, bag__remove_list/3, bag__det_remove_list/3,
  det_univ_to_type/2, list__take_upto/3, set__count/2, set_ordlist__count/2,
  store__new_cyclic_mutvar/4, relation__add_values/4,
  relation__from_assoc_list/2, relation__compose/3, varset__select/3
  and eqvclass__same_eqvclass_list/2.

  Also the old relation__to_assoc_list/2 predicate has been renamed as
  relation__to_key_assoc_list/2; there is a new relation__to_assoc_list/2
  predicate with a different type for the second argument.

  See the Mercury Library Reference Manual for details.

* A few library procedures that have implicit side effects and are thus 
  intended for debugging use only have been declared `impure'.
  You will need to write `impure' before every call to these procedures
  and typically you will need to add a `pragma promise_pure' declaration
  for the callers.

  The predicates affected are report_stats/0 and report_full_memory_stats/0
  in library/benchmarking.m; unsafe_dump/2, unsafe_dump_float/1, and
  unsafe_dump_tableaus/0 in extras/clpr/dump.m; and debug_freeze/3
  and debug_freeze/4 in extras/trailed_update/var.m.


Changes to the Mercury implementation:
**************************************

* We've added a new source-to-source transformation - deforestation.

  Deforestation transforms conjunctions to avoid the construction
  of intermediate data structures and to avoid multiple traversals
  over data structures. Deforestation is enabled at optimization level
  `-O3' or higher, or by using the `--deforestation' option.

* We've added support for "transitive" inter-module analysis.

  With the previous support for inter-module optimization, when
  analysing a module, the compiler could make use of information
  about the modules that it imports directly, but not about
  modules that are imported indirectly.  "Transitive" inter-module
  analysis gives the compiler information about indirectly
  imported modules.

  However, currently this is only used for termination analysis;
  optimizations such as inlining still use only ordinary inter-module
  analysis, not transitive inter-module analysis.

* Array bounds checking can now be disabled.

  To disable array bounds checking, you must compile with
  `--intermodule-optimization' enabled and you must also
  define the C macro ML_OMIT_ARRAY_BOUNDS_CHECKS (e.g. by using
  `MGNUCFLAGS=-DML_OMIT_ARRAY_BOUNDS_CHECKS' in your Mmake file). 
  [XXX we also need to fix problems with intermodule inlining heuristics.]

* We've added some primitive debugging support.

  The runtime system now includes a rudimentary "four-port" style debugger
  (actually with eight ports).
  To use this debugger, you need to build your program with debugging
  enabled, which is normally done using the `--debug' (or `-g') option,
  and then run it using the `mdb' command, e.g. `mdb a.out'.
  Type `h' at the `mtrace>' prompt for a list of the available commands.

  XXX We should document this in the Mercury User's Guide.

* The support for debugging using Prolog now includes support for
  detailed control over how terms are printed out during debugging.

  See the "Using Prolog" section of the Mercury User's Guide for details.

* The Mercury profiler has a number of new features.

  The profiler now supports profiling just user time, or profiling
  real (elapsed) time, rather than profiling user + system time.
  We've also added support for memory profiling.

  See the "Profiling" chapter of the Mercury User's Guide for details.

* Profiling should now work on MS Windows.

  To enable profiling on MS Windows, you need to have Sergey
  Okhapkin's latest version of gnu-win32 that includes his patch to add
  support for setitimer().  Sergey's "CoolView" version of cygwin.dll
  is available via <http://miracle.geol.msu.ru/sos/>; his patch will
  probably also be included in the next (b19) release of gnu-win32.
  Note that on Windows, you must use the Mercury runtime system's `-Tr'
  (profile real time) option; profiling just user time or user + system
  time is still not supported on Windows, because to the best of our
  knowledge Windows doesn't provide the necessary system calls.

* Intermediate files can be placed in subdirectories.

  If you use the `--use-subdirs' option to `mmake' or `mmc',
  then they will create the various intermediate files used
  by the Mercury implementation in a subdirectory called `Mercury'
  rather than in the current directory.  (For `mmake', if there
  is already a `Mercury' subdirectory, then this option is the default.)
  This keeps your source directories much less cluttered.

* Mmake has a new variable GRADEFLAGS for specifying options that
  affect the grade (compilation model).

  This means that for example to enable profiling, you can build with
  `GRADEFLAGS = --profiling' in your Mmakefile, rather than having to
  use the more obscure incantation `GRADE = asm_fast.gc.prof'.

* We've made a few small improvements to the efficiency of the generated code.

* The system has been ported to Linux/PPC.

* We've updated to version 4.12 of the Boehm garbage collector.

* Numerous bug fixes.

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