[m-dev.] proposal for promise_pure scope warning

[Ian MacLarty]

On Tue, Apr 15, 2008 at 02:09:47PM +1000, Julien Fischer wrote:
>
> On Tue, 15 Apr 2008, Ian MacLarty wrote:
>
>> On Tue, Apr 15, 2008 at 01:05:22PM +1000, Julien Fischer wrote:
>>> On Tue, 15 Apr 2008, Ian MacLarty wrote:
>>>
>>>> On Tue, Apr 15, 2008 at 9:26 AM, Peter Schachte
>>>> <schachte at csse.unimelb.edu.au> wrote:
>>>>>
>>>>>>
>>>>>>>  Well, either the author of the called predicate made it impure for a
>>>>>>>  reason, in which case you shouldn't be promising that a call to the
>>>>>>>  predicate is pure, or the author made a mistake and the predicate is
>>>>>>>  actually pure, in which case it is the author's responsibility to
>>>>>>>  fix the interface.  In any case the warning can always be disabled.
>>>>>>>
>>>>>>
>>>>>
>>>>>  Isn't it possible for one particular call to a generally impure
>>>>> predicate
>>>>> to be pure?  Eg, with that particular argument list, it's pure.
>>>>>
>>>>
>>>> I suppose so, but is this a good enough reason not to issue a warning?
>>>> I've come across bugs where this warning would have helped twice now.
>>>>
>>>> Most of the warnings issued by the compiler have cases where they
>>>> don't apply (consider for example too lax determinism warnings).  We
>>>> still issue them, because often they are helpful. In the cases where
>>>> the warning is inappropriate we usually either change the code or
>>>> disable the warning if changing the code is not possible.
>>>>
>>>> I think the warning I'm proposing would be useful enough to be worth
>>>> the slight inconvenience caused when it's not applicable.
>>>
>>> You could always have the warning turned off by default.
>>>
>>> I think you only want to emit a warning for promise_pure scopes around
>>> impure goals that do not have any outputs and have determinism det or
>>> cc_multi however.
>>>
>>
>> Why no outputs?
>>
>> Also why only if the determinism is det or cc_multi?
>>
>> If you have:
>>
>>    promise_pure ( impure p )
>>
>> where p is semidet, then surely that is an error?
>
> Maybe, but the compiler won't optimise that away because it can fail.

It depends on the context.  The compiler could optimise the following
away:

( promise_pure ( impure p ) ->
    true
;
    true
)

The same applies to the case where there is output, but the output is
not used.

> (Which is the "bug" I assume you are trying to address here)
>

That is a symptom, but the underlying problem is that purity is being
promised away in the wrong spot.  A goal like:

    promise_pure ( impure p )

just makes no sense (regardless of the determinism), because either the
goal should be impure, or p itself should be pure.

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