[m-rev.] for review: improve documentation of --fully-strict
Julien Fischer
juliensf at csse.unimelb.edu.au
Mon Sep 24 16:52:27 AEST 2007
On Mon, 24 Sep 2007, Ian MacLarty wrote:
> On Mon, Sep 24, 2007 at 03:44:40PM +1000, Julien Fischer wrote:
>>
>> On Mon, 24 Sep 2007, Ian MacLarty wrote:
>>
>>> On Mon, Sep 24, 2007 at 03:02:06PM +1000, Julien Fischer wrote:
>>>>
>>>> On Fri, 21 Sep 2007, Ian MacLarty wrote:
>>>>
>>>>> Estimated hours taken: 0.1
>>>>> Branches: main
>>>>>
>>>>> compiler/options.m:
>>>>> doc/user_guide.texi:
>>>>> Document that --no-fully-strict also replaces det goals that produce
>>>>> no outputs with `true' and goals that always fail with `fail'.
>>>>
>>>> simplify.m only does such replacements when when the goal is not impure
>>>> however.
>>>>
>>>
>>> Okay, I'll mention that the goal should not be impure.
>>>
>>>>> Also change the documented option to --no-fully-strict instead
>>>>> of --fully-strict, because --fully-strict is the default.
>>>>> XXX Should it be the default?
>>>>
>>>> I think yes; it's the least surprising choice.
>>>>
>>>
>>> The reference manual says the following:
>>>
>>> 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.
>>>
>>> This seems to suggest that the default is supposed to be
>>> --no-fully-strict.
>>>
>>> Shall I change the reference manual too then?
>>
>> Yes; I think all you need to do is change the sense of the parenthesised
>> setence that begins "The @samp{--fully-string} option ..." to "... allows
>> the
>> compiler to improve completeness ...".
>>
>
> Wouldn't the default semantics now be the *strict* commutative semantics?
Isn't that what they are anyway?
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
--------------------------------------------------------------------------
More information about the reviews
mailing list