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

[Ian MacLarty]

On Tue, Sep 25, 2007 at 01:02:25PM +1000, Julien Fischer wrote:
>
> 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.
>

How about "... (semi)pure goals that are declaratively equivalent to
true or false"?

>> +The default semantics are the strict commutative semantics.
>
> Perhaps you should list the options that imply the strict commutative
> semantics.
>

Well, if you give none of these options, then you get the strict
commutative semantics, hence they are the default semantics.

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