[m-dev.] for review: create new web pages for 0.10 release
David Overton
dmo at cs.mu.OZ.AU
Wed Feb 21 18:05:07 AEDT 2001
Hi,
Estimated hours taken: 2
Add release web pages for 0.10. This completes SourceForge task #24398.
These files still need to be linked to the rest of the web site at the
time of the release (see SourceForge task #24399).
Re quoting: I have used ` and ' for quoting since these display in
the desired way on Netscape 4.76 which does not seem to recognise the
HTML 4.0 entities ‘ and ’. (Mozilla M-18 does, however.)
w3/download/include/release-0.10.inc:
Release notes for 0.10 copied from the NEWS file.
w3/download/include/release-0.10-bugs.inc:
Known outstanding bugs for 0.10 copied from the BUGS file.
w3/download/include/release-0.10-contents.inc:
Contents of 0.10 copied from RELEASE_NOTES.
w3/download/release-0.10-bugs.php3:
w3/download/release-0.10-contents.php3:
w3/download/release-0.10.php3:
PHP3 wrappers for the above files.
Index: release-0.10-bugs.php3
===================================================================
RCS file: release-0.10-bugs.php3
diff -N release-0.10-bugs.php3
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10-bugs.php3 Wed Feb 21 17:48:30 2001
@@ -0,0 +1,9 @@
+<HTML>
+<?
+ $title="Release 0.10.0 known problems";
+ $dir="download";
+ $root="..";
+ $include="release-0.10-bugs.inc";
+ include "$root/include/template.inc"
+?>
+</HTML>
Index: release-0.10-contents.php3
===================================================================
RCS file: release-0.10-contents.php3
diff -N release-0.10-contents.php3
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10-contents.php3 Wed Feb 21 17:48:30 2001
@@ -0,0 +1,9 @@
+<HTML>
+<?
+ $title="Release 0.10.0 Contents";
+ $dir="download";
+ $root="..";
+ $include="release-0.10-contents.inc";
+ include "$root/include/template.inc"
+?>
+</HTML>
Index: release-0.10.php3
===================================================================
RCS file: release-0.10.php3
diff -N release-0.10.php3
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10.php3 Wed Feb 21 17:48:30 2001
@@ -0,0 +1,9 @@
+<HTML>
+<?
+ $title="Release 0.10.0 Notes";
+ $dir="download";
+ $root="..";
+ $include="release-0.10.inc";
+ include "$root/include/template.inc"
+?>
+</HTML>
Index: include/release-0.10-bugs.inc
===================================================================
RCS file: release-0.10-bugs.inc
diff -N release-0.10-bugs.inc
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10-bugs.inc Wed Feb 21 17:48:31 2001
@@ -0,0 +1,168 @@
+<h2>Release 0.10.0 - Known Problems</h2>
+
+The following is collected email of reported problems with release
+0.10.0 of the Mercury distribution. Included, where possible, are
+patches or work-arounds.
+<p>
+In addition to the bugs mentioned here, some bugs related
+to the implementation of particular languages features
+(existential types, nested modules, tabling)
+are also mentioned in the language reference manual, and some
+problems related to using Mercury on specific operating systems
+are described in the README.* files in the distribution.
+See also the LIMITATIONS file.
+<p>
+Note: please do not be alarmed by the fact that this software has some bugs.
+ALL useful software has bugs. During the development of the Mercury
+implementation we have found bugs in gcc, as, ld, the dynamic loader,
+and even the OS kernel. We hope that by listing the known outstanding bugs
+here we are doing our users a service. It would be disappointing if
+anyone were to infer the wrong thing from it.
+<p>
+<hr>
+<p>
+Subject: bug report - Inf and NaN
+<br>
+Date: Wed, 4 Oct 1995
+<p>
+The following module causes an "undefined variable Inf" error in the
+generated C code, because 1E400 == Infinity, which gets printed as `Inf'.
+<p>
+<pre>
+:- module hello.
+:- interface.
+:- import_module io.
+
+:- pred main(io__state::di, io__state::uo) is det.
+
+:- implementation.
+
+main -->
+ io__write_float(1E400),
+ io__write_string("\n").
+</pre>
+<p>
+<hr>
+<p>
+Subject: nit in error msg
+<br>
+Date: Thu, 16 May 1996
+<p>
+Here's another small error in an error message. If you comment out
+the [] clause for the functions car/1 or cdr/1, you get this message:
+<p>
+<pre>
+fntest.m:023: In `car(in) = out':
+fntest.m:023: Error: determinism declaration not satisfied.
+fntest.m:023: Declared `det', inferred `semidet'.
+fntest.m:023: in argument 1 of clause head:
+fntest.m:023: unification of `HeadVar__1' and `[X | V_4]' can fail.
+</pre>
+<p>
+It says Declared `det', inferred `semidet', but I never declared it at
+all. It's a bit misleading. Certainly not a major problem, and the
+later part of the message makes it quite clear what the problem is,
+but I thought I'd point it out to you before I forgot it.
+
+<p>
+<hr>
+<p>
+Subject: missed mode error
+<br>
+Date: Tue, 28 May 1996
+<p>
+Another one for the bug report file:
+<p>
+The goal `some [X, Y] X \= Y' should be a mode error,
+but the current mode checker doesn't report an error.
+Instead, the compiler goes on to generate code which gives
+the wrong answer. For example, the following program prints out `no'.
+The same problem also occurs with `some [X, Y] (X = Y -> fail ; true)'.
+<p>
+<pre>
+:- module bug.
+:- interface.
+:- import_module io.
+
+:- pred main(io__state::di, io__state::uo) is det.
+
+:- implementation.
+
+main -->
+ ( { p } -> io__write_string("yes\n") ; io__write_string("no\n") ).
+
+:- pred p is semidet.
+p :-
+ some [X, Y] X \= Y.
+</pre>
+<p>
+The bug occurs only when the variables being unified inside a negated
+context are not live, i.e. when it is the last occurrence of those variables.
+
+<p>
+<hr>
+<p>
+Subject: bug with PC values on Alpha
+<br>
+Date: Wed, 12 Jun 1996
+<p>
+On the alpha, if the Mercury runtime catches a signal, it
+sometimes prints out the wrong value for the PC (program counter).
+<p>
+<hr>
+Subject: inter-module optimization and abstract exported equivalence types.
+<br>
+Date: Thu, 19 Feb 1998
+<p>
+In some cases the compiler reports spurious ambiguity errors when compiling
+with `--intermodule-optimization'. This is due to the definition of abstract
+exported equivalence types being made visible by inter-module optimization.
+In this example, with `--intermodule-optimization' the compiler sees the
+declaration `:- type var == int' from term.m and then cannot determine whether
+`Elem' has type `int' or `pair(int)'.
+The work-around is to add an explicit type qualification.
+<pre>
+:- module foo.
+:- interface.
+:- import_module list, term.
+:- pred test(list(var)::in) is det.
+:- implementation.
+:- import_module int, std_util.
+
+test(Args0) :-
+ MakeIndex =
+ lambda([Elem0::in, Elem::out, Index0::in, Index::out] is det, (
+ Elem = Elem0 - Index0,
+ Index is Index0 + 1
+ )),
+ list__map_foldl(MakeIndex, Args0, _, 0, _).
+</pre>
+<p>
+<hr>
+<p>
+Subject: `:- pragma does_not_terminate'
+<br>
+Date: Wed, 9 Jun 1999
+<p>
+`:- pragma does_not_terminate' declarations do not work.
+The compiler's termination analysis seems to ignore them.
+<p>
+<hr>
+<p>
+Date: Wed, 1 Dec 1999
+<br>
+Subject: compiler infinite loop for cyclic type classes
+<p>
+According to the language reference manual:
+<p>
+<pre>
+| Typeclass constraints on type class declarations gives rise to a
+| superclass relation. This relation must be acyclic. That is, it is an
+| error if a type class is its own (direct or indirect) superclass.
+</pre>
+<p>
+But if you try to compile modules containing cyclic typeclasses,
+the compiler goes into an infinite loop and eventually gets a
+stack overflow, rather than reporting a proper error message.
+<p>
+<hr>
Index: include/release-0.10-contents.inc
===================================================================
RCS file: release-0.10-contents.inc
diff -N release-0.10-contents.inc
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10-contents.inc Wed Feb 21 17:48:31 2001
@@ -0,0 +1,54 @@
+<h2>Release 0.10.0 - Contents</h2>
+
+The Mercury distribution is split into three parts.
+The "mercury-compiler" distribution contains:
+<ul>
+ <li> an autoconfiguration script
+ <li> the Mercury source for the compiler
+ <li> the Mercury source for the standard library
+ <li> the automatically generated C source for the compiler
+ and the standard library
+ <li> the runtime system (written in C)
+ <li> Hans Boehm's conservative garbage collector for C
+ <li> a debugger
+ <li> a profiler
+ <li> some utility programs, including a make front-end for
+ Mercury with automatic dependency recomputation
+ <li> the Mercury language reference manual
+ <li> the Mercury library reference manual
+ <li> the Mercury user's guide
+ <li> the Mercury frequently asked questions list
+ <li> the Prolog to Mercury transition guide
+ <li> some sample Mercury programs
+</ul>
+<p>
+The "mercury-extras" distribution contains some extra libraries for:
+ <ul>
+ <li> lazy evaluation
+ <li> dynamic linking
+ <li> backtrackable (trailed) destructive update
+ <li> concurrency
+ <li> arithmetic:
+ <ul>
+ <li> arithmetic on complex and imaginary numbers
+ <li> a CLP(R) interface,
+ i.e. constraint solving over real numbers
+ </ul>
+ <li> a set of generic stream type classes
+ <li> UIs:
+ <ul>
+ <li> graphics using Tk and OpenGL
+ <li> text interfaces using curses
+ <li> processing HTML forms using the CGI interface
+ </ul>
+ <li> interfacing:
+ <ul>
+ <li> XML parsing
+ <li> POSIX interface
+ <li> an ODBC database interface
+ </ul>
+ <li> the Morphine trace analysis system
+ <li> Moose, a parser generator for Mercury
+ </ul>
+<p>
+The "mercury-tests" distribution contains a test suite.
Index: include/release-0.10.inc
===================================================================
RCS file: release-0.10.inc
diff -N release-0.10.inc
--- /dev/null Wed Nov 15 09:24:47 2000
+++ release-0.10.inc Wed Feb 21 17:48:32 2001
@@ -0,0 +1,330 @@
+
+<h2>New in release 0.10.0 of the Mercury distribution</h2>
+
+<h3>HIGHLIGHTS</h3>
+
+Changes to the Mercury language:
+<ul>
+<li> We've added support for explicit type qualification.
+<li> We've added support for tuples.
+<li> We've added support for record syntax.
+<li> Type class methods can now be defined by listing the clauses
+ directly in the instance declaration.
+<li> The syntax for defining insts and modes has been changed.
+ The old syntax is still accepted but is deprecated.
+</ul>
+
+Changes to the Mercury standard library:
+<ul>
+<li> We've added several new standard library modules:
+ <ul>
+ <li> `pprint', for pretty printing.
+ <li> `counter', for managing counters.
+ <li> `enum', a typeclass for types which can be converted to and from
+ integers.
+ <li> `sparse_bitset', an abstract data type for storing sparse sets of
+ integers or enumerations.
+ <li> `bitmap', an abstract data type for storing sets of integers.
+ <li> `hash_table', an generic hash table implementation.
+ </ul>
+<li> The `store' module now makes use of existential types.
+</ul>
+
+Changes to the Mercury implementation:
+<ul>
+<li> 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.)
+<li> There's a version of the new back-end which generates code
+ for Microsoft's new .NET system.
+<li> There's a version of the new back-end which compiles directly
+ to to assembler, using the GCC back-end.
+<li> Various improvements to `mtags'.
+
+</ul>
+
+<h3>DETAILED LISTING</h3>
+
+<h4>Changes to the Mercury language</h4>
+
+<ul>
+<li> We've added support for explicit type quantification.<p>
+
+ 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.<p>
+
+ See the "Explicit type quantification" and "Variable scoping"
+ sections of the language reference manual for details.<p>
+
+<li> 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.<p>
+
+<li> 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.<p>
+
+ 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.<p>
+
+<li> 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)'.<p>
+
+<li> The operator `^' is now used for record syntax, and cannot be
+ used for user-defined functions or constructors.<p>
+
+<li> 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.<p>
+ For example:
+ <pre>
+ GetEvens = list__filter_map(
+ (func(X) = X is semidet :- X mod 2 = 0)).
+ </pre><p>
+
+<li> 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.<p>
+
+<li> The syntax for defining insts and modes has been changed to be
+ more uniform. For example, the old syntax
+ <pre>
+ :- inst myfree = free.
+ :- mode out :: myfree -> ground.
+ </pre>
+ would now be written
+ <pre>
+ :- inst myfree == free.
+ :- mode out == myfree >> ground.
+ </pre>
+ The old syntax is still accepted but is deprecated. Support for it may
+ eventually be dropped.<p>
+
+<li> 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.<p>
+</ul>
+
+<h4>Changes to the standard library</h4>
+
+<ul>
+<li> We've added new predicates map__foldl2, tree234__foldl2,
+ std_util__aggregate2, and builtin__promise_only_solution_io.<p>
+
+<li> We've added function versions of std_util__solutions,
+ std_util__solutions_set, std_util__aggregate, map__search,
+ map__insert and map__update.<p>
+
+<li> We've added functions to allow record syntax to be used
+ with some of the types in the standard library:<p>
+ 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.<p>
+
+<li> We've added a pretty printing module, `pprint', to the standard library.<p>
+
+<li> We've added a new function to the Mercury standard library:
+ std_util__construct_tuple/1.<p>
+
+<li> 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.<p>
+
+<li> We've added reverse modes for `int__xor'.<p>
+
+<li> There is a new predicate `random__permutation', for
+ computing a random permutation of a list.<p>
+
+<li> There is a new library module `counter' for managing counters.<p>
+
+<li> We've added a new library module `sparse_bitset', which implements
+ an abstract data type for storing sets of integers.<p>
+
+<li> There is a new library module `enum' which contains a typeclass
+ describing types which can be converted to and from integers.<p>
+
+<li> 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.<p>
+
+<li> The `store' module now makes use of existential types.<p>
+
+ 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.<p>
+
+<li> We've reimplemented the `string__format/3' procedure.<p>
+
+ 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:
+ <ul>
+ <li> 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.
+
+ <li> 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.
+
+ <li> 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.
+ </ul><p>
+
+<li> We've added a new function, math__solve_quadratic/3.<p>
+<li> 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.)<p>
+
+<li> We've addes some new library predicates: assoc_list__keys_and_values,
+ list__map2 and list__map3.<p>
+
+<li> We've added func versions of the remaining preds in int.m that
+ did not already have them.<p>
+
+<li> We've added a new `bitmap' library module.<p>
+
+<li> We've added std_util__dynamic_cast/2 for type-safe runtime dynamic
+ type casting for ground types.<p>
+
+<li> We've extended the array module with array__sort/1, array__foldl/3 and
+ array__foldr/3.<p>
+
+<li> We've added a new `hash_table' library module.<p>
+
+
+</ul>
+
+<h4>Changes to the Mercury implementation</h4>
+
+<ul>
+<li> We've implemented a new back-end for the Mercury compiler.<p>
+
+ 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.<p>
+
+ 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.<p>
+
+ 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.<p>
+
+ 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:
+ <ul>
+ <li> abstractly exported equivalence types defined as `float'
+ <li> 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).
+ <li> calling copy/2 on higher-order terms
+ </ul><p>
+ It also does not support the following implemention-specific
+ features that the old back-end supports:
+ <ul>
+ <li> demangling of symbol names in the profiler
+ <li> fact tables for procedures with determinism `nondet' or `multi'
+ <li> the Mercury debugger (mdb)
+ <li> the Morphine trace analysis system
+ <li> the Aditi deductive database interface
+ <li> the `--split-c-files' option
+ <li> the `--introduce-accumulators' option
+ <li> 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'
+ </ul><p>
+
+<li> There's a new back-end that targets .NET.<p>
+
+ 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.<p>
+
+ This back-end is enabled using the new `--target il' option
+ (or just `--il' for short), or the `ilc' grade.<p>
+
+ 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.<p>
+
+ This is still work in progress.<p>
+
+ For more details, see the README.DotNet file, and
+ <a href="http://www.cs.mu.oz.au/research/mercury/dotnet.html">
+ http://www.cs.mu.oz.au/research/mercury/dotnet.html</a>.<p>
+
+<li> Native code compiler.<p>
+
+ 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.<p>
+
+ 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.<p>
+
+ 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.<p>
+
+ 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.<p>
+
+
+<li> The names of some of the `--enable-*' options to `configure' have changed.
+ See the output of `configure --help' for details.<p>
+
+<li> 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.
+</ul>
--
David Overton Department of Computer Science & Software Engineering
PhD Student The University of Melbourne, Victoria 3010, Australia
+61 3 8344 9159 http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list