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

[Julien Fischer]

On Tue, 25 Sep 2007, Ian MacLarty wrote:

> 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"?

Ok.

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