[m-dev.] call for opinions on promise_same_solutions syntax

[Julien Fischer]

On Mon, 27 Feb 2006, Zoltan Somogyi wrote:

> On a distinct but related matter, we currently consider any predicate
> defined by mode-specific clauses to be impure unless promised to be pure
> with a ":- pragma promise_pure" declaration. The problem with this is that
> ":- pragma promise_pure" is also used to promise away actual impurity
> in the clauses themselves. I think we should provide a new pragma that
> promises merely that the mode-specific clauses are equivalent *without*
> promising anything about the purity of those clauses. How about
> ":- pragma promise_equivalent_clauses"? And if we have this new pragma
> and the promise_pure scopes I added a while ago, do we need the old
> meaning of promise_pure anymore?

Most probably yes (but see below), consider this example that came up when we
were originally implementing mutables:

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

	p(!IO) :-
		promise_pure(
				impure set_mutable(3)
		).
vs.
	:- pragma promise_pure(p/2).
	:- pred p(io::di, io::uo) is det.

	p(!IO) :-
		impure set_mutable(3).

where:

	:- impure set_mutable(int::in) is det.
	:- pragma foreign_proc("C", set_mutable( ...

The problem with the former is that at many optimization levels the compiler
will happily optimize it away.

> If not, we could start the long process of deprecating it; not too many
> people will be affected. (This is related because the output variables
> listed in promise_same_solutions scopes are often mode specific, so the
> clauses they appear in must be mode specific too.)

There needs to be a more general discussion regarding the purity system
anyway, particularly w.r.t to solver types, inst any variables in negated
contexts etc.  There's was a discussion on mercury-reviews about this while
you were overseas.  See:

<http://www.cs.mu.oz.au/research/mercury/mailing-lists/mercury-reviews/mercury-reviews.200512/0052.html>

Any discussion of adding `promise_equivalent_clauses should take place as
part of this.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------