[m-rev.] for review: About page on new web site (two patches)

Peter Wang novalazy at gmail.com
Mon Apr 29 16:00:44 AEST 2013


>From 87320c2fd48796c44b88797b545c3b73b665a683 Mon Sep 17 00:00:00 2001
From: Peter Wang <novalazy at gmail.com>
Date: Fri, 26 Apr 2013 15:27:08 +1000
Subject: [PATCH 1/2] Replace top-level About page by "features" page.

The About page contained placeholder text from Wikipedia.  When I tried
to rewrite it, I only ended up reiterating the same points as on the
features page.  Move the features page up to the top-level.

The introductory paragraph is different, and more or less lifted from
Mercury papers.  It says Prolog once instead of three times.

include/about.inc:
include/menubar.inc:
about/include/features.inc:
	As above.
---
 about/include/features.inc |  190 -----------------------------------------
 include/about.inc          |  200 +++++++++++++++++++++++++++++++++++++++-----
 include/menubar.inc        |    3 -
 3 files changed, 178 insertions(+), 215 deletions(-)
 delete mode 100644 about/include/features.inc

diff --git a/about/include/features.inc b/about/include/features.inc
deleted file mode 100644
index 7cd05d6..0000000
--- a/about/include/features.inc
+++ /dev/null
@@ -1,190 +0,0 @@
-<h2>About Mercury<span class="submenutitle">/ features </span></h2>
-
-<p>
-Mercury is a new, purely declarative logic programming language.  Like
-Prolog and other existing logic programming languages, it is a very
-high-level language that allows programmers to concentrate on the
-problem rather than the low-level details such as memory management.
-Unlike Prolog, which is oriented towards exploratory programming,
-Mercury is designed for the construction of large, reliable, efficient
-software systems by teams of programmers. As a consequence, programming
-in Mercury has a different flavour than programming in Prolog.
-</p>
-<p>
-The main features of Mercury are:
-</p>
-<ul class="indentlist" id="featureslist">
-	<li>
-	<h3>
-	Mercury is purely declarative: predicates and functions in
-	Mercury do not have non-logical side effects.  
-	</h3>
-	<p>
-	Mercury does I/O through built-in and library predicates that
-	take an old state of the world and some other parameters, and
-	return a new state of the world and possibly some other
-	results. The language requires that the input argument
-	representing the old state of the world be the last reference
-	to the old state of the world, thus allowing the state of
-	the world to be updated destructively. The language also
-	requires that I/O take place only in parts of the program where
-	backtracking will not be needed.
-	</p>
-	<p>
-	Mercury handles dynamic data structures not through Prolog's
-	assert/retract but by providing several abstract data types in
-	the standard Mercury library that manage collections of items
-	with different operations and tradeoffs.
-	</p>
-	</li>
-
-	<li> 
-	<h3>
-	Mercury is a strongly typed language. 
-	</h3>
-	<p>
-	Mercury's type system is based on many-sorted logic with parametric polymorphism, very
-	similar to the type systems of modern functional languages such
-	as ML and Haskell. Programmers must declare the types they need
-	using declarations such as
-	</p>
-	<pre>
-	:- type list(T) --->	[] ; [T | list(T)].
-	:- type maybe(T) --->	yes(T) ; no.
-	</pre>
-	<p>
-	They must also declare the type signatures of the predicates they
-	define, for example
-	</p>
-	<pre>
-	:- pred append(list(T), list(T), list(T)).
-	</pre>
-	<p>
-	The compiler infers the types of all variables in the program.
-	Type errors are reported at compile time.
-	</p></li>
-
-
-	<li> 
-	<h3>
-	Mercury is a strongly moded language.
-	</h3>
-	<p>
-	The programmer must
-	declare the instantiation state of the arguments of predicates
-	at the time of the call to the predicate and at the time of the
-	success of the predicate. Currently only a subset of the
-	intended mode system is implemented. This subset effectively
-	requires arguments to be either fully input (ground at the time
-	of call and at the time of success) or fully output (free at
-	the time of call and ground at the time of success).
-	</p>
-	<p>
-	A predicate may be usable in more than one mode. For example,
-	append is usually used in at least these two modes:
-	</p>
-	<pre>
-	:- mode append(in, in, out).
-	:- mode append(out, out, in).
-	</pre>
-	<p>
-	If a predicate has only one mode, the mode information can be
-	given in the predicate declaration.
-	</p>
-	<pre>
-	:- pred factorial(int::in, int::out).
-	</pre>
-	<p>
-	The compiler will infer the mode of each call, unification and
-	other builtin in the program. It will reorder the bodies of
-	clauses as necessary to find a left to right execution order;
-	if it cannot do so, it rejects the program. Like type-checking,
-	this means that a large class of errors are detected at
-	compile time.
-	</p></li>
-
-
-	<li> 
-	<h3>
-	Mercury has a strong determinism system.
-	</h3>
-	<p>
-	For each mode of each
-	predicate, the programmer should declare whether the predicate
-	will succeed exactly once (det), at most once (semidet), at
-	least once (multi) or an arbitrary number of times (nondet).
-	These declarations are attached to mode declarations like
-	this:
-	</p>
-	<pre>
-	:- mode append(in, in, out) is det.
-	:- mode append(out, out, in) is multi.
-
-	:- pred factorial(int::in, int::out) is det.
-	</pre>
-	<p>
-	The compiler will try to prove the programmer's determinism
-	declaration using a simple, predictable set of rules that seems
-	sufficient in practice (the problem in general is undecidable).
-	If it cannot do so, it rejects the program.
-	</p>
-	<p>
-	As with types and modes, determinism checking catches many
-	program errors at compile time. It is particularly useful if
-	some deterministic (det) predicates each have a clause for each
-	function symbol in the type of one of their input arguments,
-	and this type changes; you will get determinism errors for all
-	of these predicates, telling you to put in code to cover the
-	case when the input argument is bound to the newly added
-	function symbol.
-	</p></li>
-
-	<li> 
-	<h3>
-	Mercury has a module system.
-	</h3>
-	<p>
-	Programs consist of one or more
-	modules. Each module has an interface section that contains
-	the declarations for the types, functions and predicates
-	exported from the module, and an implementation section that
-	contains the definitions of the exported entities and also
-	definitions for types and predicates that are local to the
-	module. A type whose name is exported but whose definition is
-	not, can be manipulated only by predicates in the defining
-	module; this is how Mercury implements abstract data types.
-	For predicates and functions that are not exported, Mercury
-	supports automatic type, mode, and determinism inference.
-	</p></li>
-
-	<li> <h3>Mercury supports higher-order programming,
-	with closures, currying, and lambda expressions.
-	</h3></li>
-<br/>
-	<li> 
-	<h3>
-	Mercury is very efficient
-	</h3>
-	<p>
-	Strong types, modes, and determinism
-	provide the compiler with the information it needs to generate
-	very efficient code.
-	</p>
-</ul>
-
-<p>
-The Mercury compiler is written in Mercury itself. It was bootstrapped
-using NU-Prolog and SICStus Prolog. This was possible because after
-stripping away the declarations of a Mercury program, the syntax of the
-remaining part of the program is mostly compatible with Prolog syntax.
-</p>
-<p>
-The Mercury compiler compiles Mercury programs to C, which it uses as a
-portable assembler. The system can exploit some GNU C extensions to the
-C language, if they are available: the ability to declare global
-register variables, the ability to take the addresses of labels, and
-the ability to use inline assembler. Using these extensions, it
-generates code that is significantly better than all previous Prolog
-systems known to us. However, the system does not need these
-extensions, and will work in their absence.
-</p>
diff --git a/include/about.inc b/include/about.inc
index 2d520de..8f666a1 100644
--- a/include/about.inc
+++ b/include/about.inc
@@ -1,33 +1,189 @@
 <h2>About Mercury</h2>
-<h3>What is Mercury?</h3>
-
-
-<div class="quote" style="max-width: 300px; min-width: 250px;float: right; margin: 20px 10px 40px 40px; border: 1px solid white;" align="left">
-<h2 style="font-size: 24px;color: #f15a24; font-style: italic;">“The language is designed with software engineering principles in mind.</h2>
-</div>
-
 
 <p>
-Mercury is based on the logic programming language Prolog. It has the same syntax, and the same basic concepts such as the SLD resolution algorithm. It can ostensibly be viewed as a pure subset of Prolog with strong types and modes. As such, it is often compared to its predecessor, both in terms of features, and run-time efficiency.
+Mercury is a pure logic programming language intended for the creation
+of large, fast, reliable programs.
+The syntax of Mercury is based on the syntax of Prolog, but semantically
+the two languages are very different due to Mercury's purity, its type,
+mode, determinism and module systems.
 </p>
 
 <p>
-The language is designed with software engineering principles in mind. Unlike the original implementations of Prolog, it has a separate compilation phase, rather than being directly interpreted, which allows a much wider range of errors to be caught before running a program. It features a strict static type and mode system and a module system.
+The main features of Mercury are:
 </p>
+
+<ul class="indentlist" id="featureslist">
+	<li>
+	<h3>
+	Mercury is purely declarative: predicates and functions in
+	Mercury do not have non-logical side effects.
+	</h3>
+	<p>
+	Mercury does I/O through built-in and library predicates that
+	take an old state of the world and some other parameters, and
+	return a new state of the world and possibly some other
+	results. The language requires that the input argument
+	representing the old state of the world be the last reference
+	to the old state of the world, thus allowing the state of
+	the world to be updated destructively. The language also
+	requires that I/O take place only in parts of the program where
+	backtracking will not be needed.
+	</p>
+	<p>
+	Mercury handles dynamic data structures not through Prolog's
+	assert/retract but by providing several abstract data types in
+	the standard Mercury library that manage collections of items
+	with different operations and tradeoffs.
+	</p>
+	</li>
+
+	<li>
+	<h3>
+	Mercury is a strongly typed language.
+	</h3>
+	<p>
+	Mercury's type system is based on many-sorted logic with parametric polymorphism, very
+	similar to the type systems of modern functional languages such
+	as ML and Haskell. Programmers must declare the types they need
+	using declarations such as
+	</p>
+	<pre>
+	:- type list(T) --->	[] ; [T | list(T)].
+	:- type maybe(T) --->	yes(T) ; no.
+	</pre>
+	<p>
+	They must also declare the type signatures of the predicates they
+	define, for example
+	</p>
+	<pre>
+	:- pred append(list(T), list(T), list(T)).
+	</pre>
+	<p>
+	The compiler infers the types of all variables in the program.
+	Type errors are reported at compile time.
+	</p></li>
+
+
+	<li>
+	<h3>
+	Mercury is a strongly moded language.
+	</h3>
+	<p>
+	The programmer must
+	declare the instantiation state of the arguments of predicates
+	at the time of the call to the predicate and at the time of the
+	success of the predicate. Currently only a subset of the
+	intended mode system is implemented. This subset effectively
+	requires arguments to be either fully input (ground at the time
+	of call and at the time of success) or fully output (free at
+	the time of call and ground at the time of success).
+	</p>
+	<p>
+	A predicate may be usable in more than one mode. For example,
+	append is usually used in at least these two modes:
+	</p>
+	<pre>
+	:- mode append(in, in, out).
+	:- mode append(out, out, in).
+	</pre>
+	<p>
+	If a predicate has only one mode, the mode information can be
+	given in the predicate declaration.
+	</p>
+	<pre>
+	:- pred factorial(int::in, int::out).
+	</pre>
+	<p>
+	The compiler will infer the mode of each call, unification and
+	other builtin in the program. It will reorder the bodies of
+	clauses as necessary to find a left to right execution order;
+	if it cannot do so, it rejects the program. Like type-checking,
+	this means that a large class of errors are detected at
+	compile time.
+	</p></li>
+
+
+	<li>
+	<h3>
+	Mercury has a strong determinism system.
+	</h3>
+	<p>
+	For each mode of each
+	predicate, the programmer should declare whether the predicate
+	will succeed exactly once (det), at most once (semidet), at
+	least once (multi) or an arbitrary number of times (nondet).
+	These declarations are attached to mode declarations like
+	this:
+	</p>
+	<pre>
+	:- mode append(in, in, out) is det.
+	:- mode append(out, out, in) is multi.
+
+	:- pred factorial(int::in, int::out) is det.
+	</pre>
+	<p>
+	The compiler will try to prove the programmer's determinism
+	declaration using a simple, predictable set of rules that seems
+	sufficient in practice (the problem in general is undecidable).
+	If it cannot do so, it rejects the program.
+	</p>
+	<p>
+	As with types and modes, determinism checking catches many
+	program errors at compile time. It is particularly useful if
+	some deterministic (det) predicates each have a clause for each
+	function symbol in the type of one of their input arguments,
+	and this type changes; you will get determinism errors for all
+	of these predicates, telling you to put in code to cover the
+	case when the input argument is bound to the newly added
+	function symbol.
+	</p></li>
+
+	<li>
+	<h3>
+	Mercury has a module system.
+	</h3>
+	<p>
+	Programs consist of one or more
+	modules. Each module has an interface section that contains
+	the declarations for the types, functions and predicates
+	exported from the module, and an implementation section that
+	contains the definitions of the exported entities and also
+	definitions for types and predicates that are local to the
+	module. A type whose name is exported but whose definition is
+	not, can be manipulated only by predicates in the defining
+	module; this is how Mercury implements abstract data types.
+	For predicates and functions that are not exported, Mercury
+	supports automatic type, mode, and determinism inference.
+	</p></li>
+
+	<li> <h3>Mercury supports higher-order programming,
+	with closures, currying, and lambda expressions.
+	</h3></li>
+<br/>
+	<li>
+	<h3>
+	Mercury is very efficient
+	</h3>
+	<p>
+	Strong types, modes, and determinism
+	provide the compiler with the information it needs to generate
+	very efficient code.
+	</p>
+</ul>
+
 <p>
-Due to the use of information obtained at compile time (such as type and mode information), programs written in Mercury typically perform significantly faster than equivalent programs written in Prolog. Its authors claim that Mercury is the fastest logic language in the world, by a wide margin.
+The Mercury compiler is written in Mercury itself. It was bootstrapped
+using NU-Prolog and SICStus Prolog. This was possible because after
+stripping away the declarations of a Mercury program, the syntax of the
+remaining part of the program is mostly compatible with Prolog syntax.
 </p>
 <p>
-Mercury is a purely declarative language, unlike Prolog, since it lacks "extra-logical" Prolog statements such as "cut" and imperative I/O. This enables advanced program optimization, but can make certain programming constructs (such as a switch over a number of options, with a default[dubious – discuss]) harder to express. (Note that while Mercury does allow impure functionality, this serves primarily as a way of calling foreign language code. All impure code must be explicitly marked.) Operations which would typically be impure (such as input/output) are expressed using pure constructs in Mercury using linear types, by threading a dummy "world" value through all relevant code.
+The Mercury compiler compiles Mercury programs to C, which it uses as a
+portable assembler. The system can exploit some GNU C extensions to the
+C language, if they are available: the ability to declare global
+register variables, the ability to take the addresses of labels, and
+the ability to use inline assembler. Using these extensions, it
+generates code that is significantly better than all previous Prolog
+systems known to us. However, the system does not need these
+extensions, and will work in their absence.
 </p>
-<h3>What makes Mercury special?</h3>
-<ul class="nonindentlist">
-<li>Mercury is purely declarative: predicates and functions in Mercury do not have non-logical side effects.</li>
-<li>Mercury is strongly typed language</li>
-<li>Mercury is strongly moded language</li>
-<li>Mercury has a strong determinism system</li>
-<li>Mercury has a module system</li>
-<li>Mercury supports higher-order programming, with closures, currying, and lambda expressions. </li>
-<li>Mercury is very efficient</li>
-</ul>
-
diff --git a/include/menubar.inc b/include/menubar.inc
index cb33d5a..b78ba97 100644
--- a/include/menubar.inc
+++ b/include/menubar.inc
@@ -6,9 +6,6 @@
 	<li><a href="<?php echo $root?>/about/overview.html">
 	<div <?php if($include=="overview.inc"){ ?> class="submenucurrent" <?php } ?>>
 	overview</div></a></li>
-	<li><a href="<?php echo $root?>/about/features.html">
-	<div <?php if($include=="features.inc"){ ?> class="submenucurrent" <?php } ?>>
-	features</div></a></li>
 	<li><a href="<?php echo $root?>/about/benchmarks.html">
 	<div <?php if($include=="benchmarks.inc"){ ?> class="submenucurrent" <?php } ?>>
 	benchmarks</div></a></li>
-- 
1.7.4.4

>From 82f3d300c43f41d530e6a72c50d1aff94b2289b2 Mon Sep 17 00:00:00 2001
From: Peter Wang <novalazy at gmail.com>
Date: Fri, 26 Apr 2013 15:33:16 +1000
Subject: [PATCH 2/2] Rename About "overview" page to "motivation".

about/include/motivation.inc:
about/motivation.php:
include/menubar.inc:
	As above.
---
 about/include/motivation.inc |  111 ++++++++++++++++++++++++++++++++++++++++++
 about/include/overview.inc   |  111 ------------------------------------------
 about/motivation.php         |   10 ++++
 about/overview.php           |   10 ----
 include/menubar.inc          |    4 +-
 5 files changed, 123 insertions(+), 123 deletions(-)
 create mode 100644 about/include/motivation.inc
 delete mode 100644 about/include/overview.inc
 create mode 100644 about/motivation.php
 delete mode 100644 about/overview.php

diff --git a/about/include/motivation.inc b/about/include/motivation.inc
new file mode 100644
index 0000000..d5459a8
--- /dev/null
+++ b/about/include/motivation.inc
@@ -0,0 +1,111 @@
+<h2>About Mercury<span class="submenutitle">/ motivation </span></h2>
+
+<p>
+Even though logic programming languages are theoretically superior to
+imperative programming languages such as C, C++, Pascal and Ada,
+existing logic programming languages such as Prolog are not widely used
+in industry for writing application programs.  The two main reasons for
+this are
+</p>
+
+<ul class="indentlist">
+<li>
+Compilers for current logic programming languages detect many fewer
+errors in programs than compilers for imperative programming languages
+do.  Programmers therefore have to find all the errors themselves,
+usually with minimal debugging support.  This significantly reduces
+productivity.</li>
+<br/>
+<li>
+Implementations of logic programming languages are significantly slower
+than the implementations of imperative languages such as C.  Therefore
+the designers of applications where performance is important do not even
+consider logic programming languages.
+</li>
+</ul>
+
+<p>
+We are developing a new kind of logic programming language that solves
+both of these problems.  Our new language, Mercury, has strong type and
+mode systems that detect a large percentage of program errors at compile
+time.  The information provided by the type and mode systems then allows
+us to significantly increase the efficiency of the implementation.
+Meanwhile, unlike Prolog, Mercury retains all the desirable properties
+of logic programming languages.  For example, the absence of side
+effects in Mercury by itself prevents large classes of errors that
+plague programs written in imperative languages.  It also allows us to
+transform and optimize Mercury programs in ways that are emphatically
+not possible with programs written in imperative languages or in Prolog.
+For example, it is straightforward to integrate intelligent backtracking
+into Mercury, even though researchers have given up on doing the same
+for Prolog.
+</p>
+
+
+<div class="quote" style="max-width: 450px; min-width: 250px;float: right; margin: 40px 10px 40px 60px; border: 1px solid white;" align="left">
+<h2 style="font-size: 24px;color: #9e005d; font-style: italic;">
+“Mercury has strong type and mode systems that detect a large percentage of program errors at compile time. 
+</h2>
+</div>
+
+
+<p>
+We are writing the Mercury compiler in Mercury itself.  We used
+NU-Prolog and SICStus Prolog for boot-strapping until the compiler was
+able to compile itself.  The compiler's type, mode and determinacy
+checkers have together prevented several hundred bugs in the compiler
+itself.  Traditional Prolog systems cannot make such checks.  Therefore
+had we been programming only in Prolog, many of these bugs would not
+have been detected, and locating the rest would have required manual
+tracing of the compiler's execution, taking several hours per bug.  As
+it is, the Mercury compiler pinpointed these bugs automatically, and due
+to the help of the error messages, we have found that most bugs were
+quite easy to fix.
+</p>
+<p>
+Our experience strongly supports our initial conjecture that Mercury is
+a comfortable language to program in, and that it is much easier to
+produce reliable programs in Mercury than in Prolog.  The amount of
+functionality we have implemented so far also strongly suggests that it
+is easier to produce reliable programs in Mercury than in imperative
+languages such as C, C++, Pascal or Ada.
+</p>
+<p>
+Our extensive benchmarking has shown our implementation to be almost
+twice as fast as the fastest existing logic programming system, Aquarius
+Prolog, about five times as fast as SICStus Prolog's native mode
+compiler, about ten times as fast as Quintus Prolog, and 20 to 36 times
+as fast as other Prolog implementations using bytecode interpreters.
+</p>
+<p>
+Mercury does not sacrifice portability for speed.  While previous fast
+logic programming systems generate native code and can thus run on only
+few types of system, we generate C code that can be compiled on almost
+all software and hardware platforms.
+</p>
+<p>
+Aquarius and other high-performance Prolog systems base their
+optimizations on information gathered by global analysis.  These
+analyses must make approximations to keep analysis times reasonable.
+Large programs tend to require more approximations, which makes
+optimization less effective.  Despite using only predicate-level and
+module-level analyses, Mercury never makes approximations, and thus
+retains its speed even for the largest programs.
+</p>
+<p>
+We designed the Mercury execution algorithm in October 1993.
+We started working on a Mercury compiler in December 1993.
+Semantic analysis started working around May 1994.
+We started generating code around August 1994;
+we started work on optimizations very soon after.
+The compiler successfully compiled itself on 24 February 1995.
+The first public beta release of the system was version 0.3 on 18 July 1995.
+The profiler was introduced in Version 0.4 on 15 September 1995.
+Checking of uniqueness information and the C language interface
+were introduced in Version 0.5 on 15 February 1996.
+Functional syntax and type and mode inference
+were introduced in Version 0.6 on 2 August 1996.
+Version 0.7, released on 15 August 1997,
+introduced generic I/O predicates and
+was the first to provide cross-module optimization.
+</p>
diff --git a/about/include/overview.inc b/about/include/overview.inc
deleted file mode 100644
index fcc66bd..0000000
--- a/about/include/overview.inc
+++ /dev/null
@@ -1,111 +0,0 @@
-<h2>About Mercury<span class="submenutitle">/ overview </span></h2>
-
-<p>
-Even though logic programming languages are theoretically superior to
-imperative programming languages such as C, C++, Pascal and Ada,
-existing logic programming languages such as Prolog are not widely used
-in industry for writing application programs.  The two main reasons for
-this are
-</p>
-
-<ul class="indentlist">
-<li>
-Compilers for current logic programming languages detect many fewer
-errors in programs than compilers for imperative programming languages
-do.  Programmers therefore have to find all the errors themselves,
-usually with minimal debugging support.  This significantly reduces
-productivity.</li>
-<br/>
-<li>
-Implementations of logic programming languages are significantly slower
-than the implementations of imperative languages such as C.  Therefore
-the designers of applications where performance is important do not even
-consider logic programming languages.
-</li>
-</ul>
-
-<p>
-We are developing a new kind of logic programming language that solves
-both of these problems.  Our new language, Mercury, has strong type and
-mode systems that detect a large percentage of program errors at compile
-time.  The information provided by the type and mode systems then allows
-us to significantly increase the efficiency of the implementation.
-Meanwhile, unlike Prolog, Mercury retains all the desirable properties
-of logic programming languages.  For example, the absence of side
-effects in Mercury by itself prevents large classes of errors that
-plague programs written in imperative languages.  It also allows us to
-transform and optimize Mercury programs in ways that are emphatically
-not possible with programs written in imperative languages or in Prolog.
-For example, it is straightforward to integrate intelligent backtracking
-into Mercury, even though researchers have given up on doing the same
-for Prolog.
-</p>
-
-
-<div class="quote" style="max-width: 450px; min-width: 250px;float: right; margin: 40px 10px 40px 60px; border: 1px solid white;" align="left">
-<h2 style="font-size: 24px;color: #9e005d; font-style: italic;">
-“Mercury has strong type and mode systems that detect a large percentage of program errors at compile time. 
-</h2>
-</div>
-
-
-<p>
-We are writing the Mercury compiler in Mercury itself.  We used
-NU-Prolog and SICStus Prolog for boot-strapping until the compiler was
-able to compile itself.  The compiler's type, mode and determinacy
-checkers have together prevented several hundred bugs in the compiler
-itself.  Traditional Prolog systems cannot make such checks.  Therefore
-had we been programming only in Prolog, many of these bugs would not
-have been detected, and locating the rest would have required manual
-tracing of the compiler's execution, taking several hours per bug.  As
-it is, the Mercury compiler pinpointed these bugs automatically, and due
-to the help of the error messages, we have found that most bugs were
-quite easy to fix.
-</p>
-<p>
-Our experience strongly supports our initial conjecture that Mercury is
-a comfortable language to program in, and that it is much easier to
-produce reliable programs in Mercury than in Prolog.  The amount of
-functionality we have implemented so far also strongly suggests that it
-is easier to produce reliable programs in Mercury than in imperative
-languages such as C, C++, Pascal or Ada.
-</p>
-<p>
-Our extensive benchmarking has shown our implementation to be almost
-twice as fast as the fastest existing logic programming system, Aquarius
-Prolog, about five times as fast as SICStus Prolog's native mode
-compiler, about ten times as fast as Quintus Prolog, and 20 to 36 times
-as fast as other Prolog implementations using bytecode interpreters.
-</p>
-<p>
-Mercury does not sacrifice portability for speed.  While previous fast
-logic programming systems generate native code and can thus run on only
-few types of system, we generate C code that can be compiled on almost
-all software and hardware platforms.
-</p>
-<p>
-Aquarius and other high-performance Prolog systems base their
-optimizations on information gathered by global analysis.  These
-analyses must make approximations to keep analysis times reasonable.
-Large programs tend to require more approximations, which makes
-optimization less effective.  Despite using only predicate-level and
-module-level analyses, Mercury never makes approximations, and thus
-retains its speed even for the largest programs.
-</p>
-<p>
-We designed the Mercury execution algorithm in October 1993.
-We started working on a Mercury compiler in December 1993.
-Semantic analysis started working around May 1994.
-We started generating code around August 1994;
-we started work on optimizations very soon after.
-The compiler successfully compiled itself on 24 February 1995.
-The first public beta release of the system was version 0.3 on 18 July 1995.
-The profiler was introduced in Version 0.4 on 15 September 1995.
-Checking of uniqueness information and the C language interface
-were introduced in Version 0.5 on 15 February 1996.
-Functional syntax and type and mode inference
-were introduced in Version 0.6 on 2 August 1996.
-Version 0.7, released on 15 August 1997,
-introduced generic I/O predicates and
-was the first to provide cross-module optimization.
-</p>
diff --git a/about/motivation.php b/about/motivation.php
new file mode 100644
index 0000000..e40937b
--- /dev/null
+++ b/about/motivation.php
@@ -0,0 +1,10 @@
+<HTML>
+<?php
+    $menu="About";
+    $title="Overview and Motivation";
+    $dir="about";
+    $root="..";
+    $include="motivation.inc";
+    include "$root/include/template.inc"
+?>
+</HTML>
diff --git a/about/overview.php b/about/overview.php
deleted file mode 100644
index a5c635c..0000000
--- a/about/overview.php
+++ /dev/null
@@ -1,10 +0,0 @@
-<HTML>
-<?php
-    $menu="About";
-    $title="Overview and Motivation";
-    $dir="about";
-    $root="..";
-    $include="overview.inc";
-    include "$root/include/template.inc"
-?>
-</HTML>
diff --git a/include/menubar.inc b/include/menubar.inc
index b78ba97..883732d 100644
--- a/include/menubar.inc
+++ b/include/menubar.inc
@@ -3,9 +3,9 @@
 	<?php
 	if($menu == "About") { ?>
 	<ul class="submenu">
-	<li><a href="<?php echo $root?>/about/overview.html">
+	<li><a href="<?php echo $root?>/about/motivation.html">
 	<div <?php if($include=="overview.inc"){ ?> class="submenucurrent" <?php } ?>>
-	overview</div></a></li>
+	motivation</div></a></li>
 	<li><a href="<?php echo $root?>/about/benchmarks.html">
 	<div <?php if($include=="benchmarks.inc"){ ?> class="submenucurrent" <?php } ?>>
 	benchmarks</div></a></li>
-- 
1.7.4.4





More information about the reviews mailing list