[m-dev.] proposal for promise_pure scope warning

[Ian MacLarty]

On Tue, Apr 15, 2008 at 01:40:45PM +1000, Peter Schachte wrote:
> Ian MacLarty wrote:
>> On Tue, Apr 15, 2008 at 9:26 AM, Peter Schachte
>>>  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.
>
> I guess this is what I don't understand.  How could you accidentally wrap a 
> promise_pure around a goal?  Hang on, is this because promise_pure is an 
> operator that binds too tightly, so users think they've promised a sequence 
> of goals to be pure when they've only promised a singlg goal?  If it's 
> that, then maybe changing the precedence would be better.
>

The problems I've seen are when the user wants to make something pure by
adding the IO state.  They usually do:

:- pred pure_p(..., io::di, io::uo) is det.

pure_p(..., !IO) :-
    promise_pure ( impure impure_p(...) ).

Which is wrong.  It should be:

:- pragma promise_pure(pure_p).

pure_p(..., !IO) :-
    impure impure_p(...).

>> 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.
>
> If you're going to issue a warning for something that may be correct, there 
> should be a low-nuisance way to disable the warning just for that 
> occurrence.  Like beginning a variable name with _ to disable the 
> singleton warning. How would you do it for this warning?

Either declare the called pred pure, or put the promise_pure
around more goals in the body, or move it into a pragma.

> I hope it's not 
> to conjoin it with a 'true' goal so it won't be a single goal....

As a last resort you could do that.  Or put
--no-warn-singleton-promise-pure-goals in your Mercury.options.  But
really when would you actually have a legitimate single impure atomic
goal in a promise_pure?  You mentioned the case where it could be pure
with some args and impure with others, but then why wouldn't you move
the promise_pure up to where you test whether the inputs imply a pure or
impure call, or use a pragma promise_pure instead?

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