[m-rev.] for review: improve documentation of --fully-strict

[Julien Fischer]

On Tue, 25 Sep 2007, Ian MacLarty wrote:

> Index: doc/reference_manual.texi
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/doc/reference_manual.texi,v
> retrieving revision 1.408
> diff -u -r1.408 reference_manual.texi
> --- doc/reference_manual.texi	13 Sep 2007 03:35:05 -0000	1.408
> +++ doc/reference_manual.texi	25 Sep 2007 02:14:05 -0000
> @@ -6135,14 +6135,14 @@
> Programmers who care about efficiency more than portability can write
> code for these implementation-defined semantic models.  Programmers who
> care about efficiency @emph{and} portability can achieve this by writing
> -code for the commutative semantics.
> +code for the strict commutative semantics.
> Of course, this is not
> quite as easy as using the strict sequential semantics, since it is
> in general not sufficient to test your programs on just one
> implementation if you are to be sure that it will be able to use the
> maximally efficient operational semantics on any implementation.
> However, if you do write code which works for all possible executions
> -under commutative semantics (i.e.@: for all possible orderings of
> +under the strict commutative semantics (i.e.@: for all possible orderings of
> conjunctions and disjunctions), then you can be guaranteed that it
> will work correctly on every implementation, under every possible
> implementation-defined semantics.
> @@ -6150,12 +6150,15 @@
> The University of Melbourne Mercury implementation offers eight
> different semantics, which can be selected with different
> combinations of the @samp{--no-reorder-conj}, @samp{--no-reorder-disj},
> -and @samp{--fully-strict} options.  (The @samp{--fully-strict} option
> -prevents the compiler from improving completeness by optimizing away infinite
> -loops or calls to @code{require.error/1} or @code{exception.throw/1}.)
> -The default semantics are the commutative semantics.  Enabling all of these
> -options gives you the strict sequential semantics.  Enabling just some
> -of them gives you a semantics somewhere in between.
> +and @samp{--no-fully-strict} options.
> +(The @samp{--no-fully-strict} option allows the compiler to improve
> +completeness by optimizing away infinite loops,
> +calls to @code{require.error/1} or @code{exception.throw/1},
> +pure or semipure goals that always succeed and produce no outputs,
> +or pure or semipure goals that always fail.)

That reads a little awkwardly.  How about:

 	..., (semi)pure goals that are equivalent and (semi)pure goals
 	that are equivalent to true.

> +The default semantics are the strict commutative semantics.

Perhaps you should list the options that imply the strict commutative
semantics.

> +Enabling @samp{--no-reorder-conj} and @samp{--no-reorder-disj} gives the
> +strict sequencial semantics.

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------