[m-rev.] For review: change the way we handle inst any non-locals in negated contexts (again)

[Julien Fischer]

On Thu, 15 Dec 2005, Mark Brown wrote:

> On 15-Dec-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> > On Thu, 15 Dec 2005, Mark Brown wrote:
> > > On 15-Dec-2005, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > > > Just as a matter of style, it would be bad to have `promise_pure' on
> > > > an exported predicate; in that case I'd use the pragma instead.
> > >
> > > That's a good point, and one I didn't consider.  The intent was actually to
> > > abolish that pragma entirely -- it never seemed right to me that the promise
> > > was made via a pragma, even though such pragmas are currently considered
> > > a standard part of the language (see the start of chapter 16).  The rules
> > > I've set out imply that this append definition will be inferred impure, and
> > > therefore that an annotation on the declaration would be necessary -- either
> > > impure, promise_pure or promise_semipure.
> > >
> > > However, the principle that implementation details shouldn't have to be
> > > exposed in the interface is a good one, so perhaps we should keep the
> > > pragmas after all, or find some other way to make the promise in the
> > > implementation.  Anyone got any suggestions?
> > >
> >
> > I would still like to get rid of the pragma - I don't think promise_pure
> > should be a pragma at all.  Since the proposal adds promise_(semi)pure
> > annotations maybe we don't need to annotate the predicate declarations
> > at all.  If you want promise something is (semi)pure then just put a
> > promise_(semi)pure annotation on the top-level goal.
>
> That won't be able to express what we want.  A predicate or function
> definition (as opposed to a goal) can be inferred impure for a number
> of reasons:
>
> 	- because the body is impure,
> 	- because it has a foreign_proc,
> 	- because it has different code for different modes.
>
> Placing a promise on the top-level goal (that is, on the body) will deal with
> the first of these, and there are foreign_proc attributes that can deal with
> the second.  But the only way to deal with the third is to have a promise
> in the declaration, or in some other item like a pragma.
>

For mode-specific clauses can't we just require that each clause must have
a purity annotation on its top-level goal (if it is a Mercury clause) or
promise_pure attribute if it is a foreign clause.

Failing that, I think we should just introduce promise_(semi)pure
declarations in place of the pragmas and not bother putting promise_*
annotations on the pred decls.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------