Re: looking for an alternative to prolog
From: Fergus Henderson (fjh_at_cs.mu.oz.au)
Date: 01/19/04
- Previous message: Jan Wielemaker: "Re: Prolog & C linking Problem"
- In reply to: Greg Lorriman: "looking for an alternative to prolog"
- Next in thread: Amzi! inc.: "Re: looking for an alternative to prolog"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 19 Jan 2004 11:10:12 GMT
temp@lorriman.com (Greg Lorriman) writes:
>I'm looking to learn a practical (industrially so) declarative
>language. For this reason and others (like difficulties of debugging)
>I believe that prolog may not be the language for me. Whether or not I
>am right (I am not really in a position to argue the point) I was
>wandering whether you folks could point me in the right direction.
If that is the sort of language that you are looking for, then
Mercury sounds like the natural choice.
>Mercury was given to me as a possibility, however it would seem that
>its maturity is doubtful
Mercury was first publically released in 1995.
We have made new releases available about once a year since then.
Mercury now comes with three profilers, three debuggers,
six different compiler back-ends, and two different garbage collectors.
There are numerous add-ons that provide support for additional features
(concurrency, dynamic libraries, lazy evaluation, parsing/lexing, etc.)
or that provide interfaces to other systems.
The only reason why we don't have a "1.x" version number at this point
is that we do not yet have support for a couple of features that we
envisaged as being part of the original design for the mode system,
namely modes that make use of partially instantiated data structures
or partial uniqueness. Unless you need those features, you should not
read anything into the version number apart from the message that we
(the Mercury developers) set ourselves high standards.
>development of it seem quite slow.
Why do you say that development seems slow?
To get an idea of the progress that we are making, perhaps you should
take a look at some of the 245 messages posted to our main development
lists (mercury-reviews and mercury-developers) last month.
See <http://www.cs.mu.oz.au/research/mercury/mailing-lists/mailing-lists.html>.
We only make official releases every year or so, because making a new
official release is a lot of work -- we put in a lot of effort into
testing official releases on a large variety of different platforms.
But we make snapshot releases of our development sources available
on a daily basis. "stable" versions of our development sources --
those which have passed *every* test in our extensive test suite --
are released at least every couple of months (and sometimes much more
frequently than that).
I enclose below a list of changes since our last official release.
It is reasonable to be concerned about the possibility that Mercury
development might slow down in the future, as people like myself and
Simon Taylor are likely to move on to other things. However,
Zoltan Somogyi looks set to continue working on Mercury for the
forseeable future, and he is still at least a good 20 years off
retirement age ;-) Other members of the Mercury group such as Ralph
Becket also have a long-term academic future in Melbourne and are
likely to continue working on Mercury. There are also new students such
as James Goddard (a new summer student) and Sam Haldane (a new honours
student) coming up through the ranks.
NEWS since Mercury release 0.11.0:
----------------------------------
HIGHLIGHTS
==========
Changes to the Mercury language:
* Infix `.' is now accepted as a module name separator.
* Field access syntax can now be used at the top-level in func and mode
declarations and in the head of a clause for a user-defined field access
function.
* We now support impure higher-order code.
* We now allow user-defined comparison predicates.
* User-defined equality and comparison predicates for a type are now
required to be defined in the same module as the type.
Changes to the Mercury compiler:
* We have added optional support for a new type-accurate garbage collector
as an alternative to using the Boehm et al conservative collector.
* Better support for incremental program development:
there's two new compiler options, `--allow-stubs' and `--no-warn-stubs',
to support execution of incomplete programs.
* There's a new warning option `--warn-dead-procs' for detecting unreachable
code.
* It's now easier to use shared libraries on Linux/x86 systems
with `mmc --make'.
Changes to the Mercury standard library:
* We've added two new modules: cord, for sequences with O(1) consing and
concatenation, and array2d, for two-dimensional arrays.
* New procedures have been added to many of the existing standard library
modules. Most notably, these include procedures for creating
directories and symbolic links, for checking file types and file
accessibility, for detecting floating point infinities and NaNs.
* The dir module now handles Microsoft Windows pathnames correctly.
Portability improvements:
* Nothing yet.
Changes to the Mercury debugger:
* Users can now limit the output from stack traces.
Changes to the compiler back-ends:
* The .NET CLR back-end now bootstraps.
* Significant improvements to the Java back-end.
Numerous minor improvements to the Mercury standard library.
DETAILED LISTING
================
Changes to the Mercury language:
* We now allow user-defined comparison predicates, using the syntax
:- type t ---> t where equality is unify_t, comparison is compare_t.
See the "User-defined equality and comparison" chapter of the
Mercury Language Reference Manual for details.
* User-defined equality and comparison predicates for a type are now
required to be defined in the same module as the type.
* Infix `.' is now accepted as a module name separator. Hence it is
now possible to write io.write_string and list.member to mean the
same thing as io__write_string and list__member, for instance. This
has required changing the associativity of `.' from xfy to yfx and
from precedence 600 to 10.
* Field access notation can now be used at the top-level in func and
mode declarations and in the head of a clause for a user-defined
field access function. That is, one can now write
:- func a ^ f(b) = c.
:- mode a ^ f(b) = c is <detism>.
A ^ f(B) = ...
* Mercury's support for impure code now also includes support for
impure higher-order code.
Specifically, impurity annotations can be used on higher-order types,
lambda expressions, and higher-order calls; higher-order terms are
permitted to call impure or semipure code provided that they are
appropriately annotated as such.
For details, see the "Higher-order impurity" section of the "Impurity"
chapter of the Mercury Language Reference Manual.
* The (undocumented) support for dynamic modes and constraint solving
has changed. Types which may have dynamic modes must now be declared
using ":- solver type" instead of ":- type".
Changes to the Mercury standard library:
* We've added a new library module, `array2d', for two-dimensional arrays.
* We've added a new module, cord, for sequences with O(1) consing and
concatenation. A cord is essentially a tree structure with data stored
in the leaf nodes. Joining two cords together to construct a new cord
is therefore an O(1) operation.
* The dir module now handles Microsoft Windows pathnames correctly.
* dir__split_name and dir__basename are now semidet, not det.
dir__split_name fails for root directories or pathnames not
containing a directory separator.
dir__basename fails for root directories.
* We've added some new predicates and functions to the dir module:
basename_det/1,
expand_braces/1,
is_directory_separator/1,
make_directory/4,
make_single_directory/4,
foldl2/6,
parent_directory/0,
path_name_is_absolute/1,
path_name_is_root_directory/1,
recursive_foldl2/7.
* We've added several new predicates to the io module:
have_symlinks/0,
make_symlink/4,
follow_symlink/4,
check_file_accessibility/5,
file_type/4,
input_stream_foldl2_io_maybe_stop/{6,7},
binary_input_stream_foldl2_io_maybe_stop/{6,7}.
* We've added predicates relation__lookup_key_set_from/3 and
relation__lookup_key_set_to/3.
* The type of the arguments giving the initial set of visited nodes
to relation__dfs and relation__dfsrev has changed from set_bbbtree
to sparse_bitset.
* Efficiency of the operations in the relation module has been
greatly improved.
* Some predicates and functions have been added to the sparse_bitset module:
to_set/1,
from_set/1,
member/2,
foldl/4,
foldr/4.
* exception.m now contains a predicate finally/6 which can be used to
ensure that resources are released whether a called closure exits
normally or throws an exception.
* We've added predicates multi_map.to_flat_assoc_list/2 and
multi_map.from_flat_assoc_list/2.
* Several new functions have been added to the string module, namely
elem/2, unsafe_elem/2, chomp/1, lstrip/1, lstrip/2, rstrip/1, rstrip/2,
strip/1, prefix_length/2, and suffix_length/2.
* We've added some new predicates, list__map2_foldl, list__map_foldl3,
and list__foldl4 to list.m.
* We've added some new predicates, map__common_subset and map__foldl3,
to map.m.
* We've added a predicate, map_fold, to set.m.
* We've added a function, pred_to_bool, to bool.m.
* We've added the three predicates, `is_nan/1', `is_inf/1' and
`is_nan_or_inf/1' to float.m. These predicates are for use only on
systems which support IEEE floating point arithmetic.
* We've added a function version of `hash_table__search/3'.
* getopt.m now accepts a `maybe_string_special' option type.
* We've added a predicate, copy_mutvar, to store.m.
* We've added a function, clk_tck, to time.m.
* builtin.m now contains types and insts `unify' and `compare' for use
in defining user-defined equality and comparison predicates.
* We've fixed some problems with the use of `cc_nondet'.
The incorrect cc_nondet modes of the following predicates have been removed:
deconstruct.arg/4
deconstruct.named_arg/4
deconstruct.limited_deconstruct/6
std_util.arg_cc/3
std_util.argument_cc/3
std_util.named_argument_cc/3
std_util.limited_deconstruct_cc/5
These have been replaced by cc_multi versions in which success or failure
is indicated by returning a maybe type.
* The following predicates, which were added in 0.11.0, have been deprecated:
io.current_input_stream/3
io.current_output_stream/3
io.current_binary_input_stream/3
io.current_binary_output_stream/3
They were identical to the following long-existing predicates with
similar names:
io.input_stream/3
io.output_stream/3
io.binary_input_stream/3
io.binary_output_stream/3
* We've added some constant functions, integer.zero/0 and integer.one/0
to integer.m. We have also added a function version of integer.pow/3.
* We've added some functions, rational.int/1, rational.from_integer/1
and rational.from_integers/2 to rational.m
The function rational.rational_from_integers/2 has been deprecated.
Changes to the extras distribution:
* Nothing yet.
Changes to the Mercury compiler:
* We have added optional support for a new type-accurate garbage collector
as an alternative to using the Boehm et al conservative collector.
The new collector is enabled by `--grade hlc.agc'.
For details about how it works, see the paper
"Accurate garbage collection in an uncooperative environment"
which is available via our web page.
Note that the new collector is a very naive copying collector, and still
has a number of serious limitations which may make it undesirable for
most applications. It only works with `--high-level-code'. The heap
size is fixed at program startup; the collector does not attempt to
resize the heap. It does not do cheap heap reclamation on backtracking.
There is no support for passing terms on the Mercury heap to C code.
In most cases, the Boehm et all conservative collector will perform better.
* There's a new warning option `--warn-dead-procs' which can be used
for detecting unreachable code.
This is not yet enabled by default, because it can cause some spurious
warnings in modules containing code which mixes Mercury clauses and
`pragma foreign_proc' declarations for the same procedure.
* `mmc --make' now works correctly with Microsoft Visual C++.
* It's now easier to use shared libraries on Linux/x86 systems with
`mmc --make'. See the documentation for the `--mercury-linkage'
and `--linkage' options and the `MERCURY_LINKAGE' Mmake variable
in the Mercury User's Guide.
* The behaviour of the `--pre-link-command' and `--extra-init-command'
options has changed. They now take a command which will be passed
the names of all source files in the program or library, with the
name of the main module's source file passed first.
See the "Build system options" section of the "Invocation" chapter
of the Mercury User's Guide for details.
* It is now possible to reconfigure an existing Mercury installation
to use a different C compiler. See the "C compilers" chapter
of the Mercury User's Guide for details.
* Inlining of builtins can now be disabled using the `--no-inline-builtins'
option. This is done by default when debugging, as without this option the
execution of builtins is not traced.
* The Mercury compiler now uses `.' and not `:' as the module separator
in all output.
* The environment variables which were previously used to override the
location of the standard library (MERCURY_ALL_C_INCL_DIRS,
MERCURY_ALL_MC_C_INCL_DIRS, MERCURY_INT_DIR, MERCURY_C_LIB_DIR,
MERCURY_MOD_LIB_MODS, MERCURY_TRACE_LIB_MODS) have been removed.
Portability improvements:
* Nothing yet.
Changes to the Mercury debugger:
* Nothing yet.
Changes to the compiler back-ends:
* The .NET CLR back-end now bootstraps.
We've fixed a lot of bugs, and implemented a lot more of the Mercury
standard library. As well as being able to bootstrap in grade `il',
we also now pass more than 90% of the applicable tests in the
Mercury test suite. See README.DotNet for details.
* Significant improvements to the Java back-end.
We've fixed a lot of bugs, and implemented a lot more of the Mercury
standard library.
-- Fergus Henderson <fjh@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.
- Previous message: Jan Wielemaker: "Re: Prolog & C linking Problem"
- In reply to: Greg Lorriman: "looking for an alternative to prolog"
- Next in thread: Amzi! inc.: "Re: looking for an alternative to prolog"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
