[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, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > Mark Brown, Thursday, 15 December 2005:
> > > @@ -2910,18 +2912,16 @@
> > >
> > >  Because of this possibility, predicates or functions which are defined
> > >  using different code for different modes are by default assumed to be
> > > -impure; the programmer must either (1) carefully ensure that the
> > > -logical meaning of the clauses is the same for all modes,
> > > -in which case a @samp{pragma promise_pure} declaration can be used
> > > -or (2) declare the predicate or function as impure.
> > > +impure; the programmer must therefore place a purity annotation on the
> > > +declaration.
> > >  @xref{Impurity}.
> > >
> > >  In the example with @samp{append} above, the two ways of implementing
> > > -append do have the same declarative semantics, so we can safely use
> > > -the first approach:
> > > +append do have the same declarative semantics, so we can safely promise
> > > +it to be pure:
> > >
> > >  @example
> > > -	:- pragma promise_pure(append/3).
> > > +	:- promise_pure pred append(list(T), list(T), list(T)).
> > >  @end example
> >
> > 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.

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