[m-dev.] proposal for promise_pure scope warning

Ian MacLarty maclarty at csse.unimelb.edu.au
Tue Apr 22 11:19:40 AEST 2008

On Tue, Apr 15, 2008 at 05:06:34PM +1000, Julien Fischer wrote:
> On Tue, 15 Apr 2008, Ian MacLarty wrote:
>> ( 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.
> The G12 FD solver uses constructs like the above extensively (which
> is one reason I don't want any warning to be enabled by default).

Julien showed me the constructs in the FD solver and they go something
like the following:

    impure invoke(p(A, B))

where A and B have any insts and p(A, B) is a closure.

Now in superhomogeneous form this will be:

    P = p(A, B),

and at the point I want to issue the warning (purity.m) the program
would have been transformed into superhomogeneous form, so no warning
will be issued for this case.

The warning would still however be issued for cases like:

    promise_pure ( impure turn_off_profiling )

as well as in the cases given by Peter in the caching example.

It seems weird to do the check after the program is transformed into
superhomogeneous form, but I think that actually makes more sense, since
then any inline constructions or function calls (which might affect the
purity) have been moved into separate atomic goals.

What do you think of this idea?

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

More information about the developers mailing list