[m-dev.] for review: impure functions

[Tyson Dowd]

On 05-Apr-2000, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> 
> It would be nice to eventually be able to have dcg goals of the form
> 	...
> 	impure =(an_impure_function(...))
> 	...
> or
> 	...
> 	impure :=(an_impure_function(...))
> 	...

I'll put it in as a wish-list comment.  I just noticed I have to
also update the comments at the top of purity.m, so I'll put it in
there.  I think nobody will ever use it, but that has that stopped a
feature being implemented.

> > +	; { PurityCheckResult = no_impure_in_closure },
> > +			% We catch this error at the creation of the closure
> > +			% It might also make sense to flag missing
> > +			% impurity declarations inside closures, but we
> > +			% don't do so currently.
> > +		{ NumErrors = NumErrors0 }
> 
> Do you mean that we don't give an error for a call to an impure pred without
> an `impure' annotation inside a closure? If so, you should mark that with
> an XXX at least.

We give an error,  it's just that we give an error about the entire closure
being impure, not individual calls inside it.

The rationale for this is that you don't really want to force the user
to fix all the `impure' annotations on their calls inside the closure,
and then be told by the compiler "oh, but you can't have impure closures
anyway".

If you could flag the missing declarations in a way that made it clear
to the user that fixing the errors wouldn't help anyway, it might be
worthwhile (so they can pinpoint the source of the impurity perhaps).
But it's more a wish-list item than an XXX.  It would require a bit of
extra work to report, and it's not clear it's worthwhile for anyone
but the most weenie developers (who shouldn't be messing with impure
anyway!).   I could be convinced on the usefulness of the error message
though.

(I'm thinking of allowing impure closures one day.  I think they
might be useful when writing callbacks).

> > +		;
> > +			{ goal_info_get_context(GoalInfo, CallContext) },
> > +			error_unknown_predicate(CallContext),
> > +			{ Purity = pure },
> > +			{ NumErrors is NumErrors0 + 1 }
> 
> Doesn't this else case correspond to unresolved overloading, and therefore
> wouldn't this error be reported elsewhere?

Unresolved type inference of some sort.

Yes it will be reported elsewhere, but I think it is better for purity
to make some noise along the lines of "typecheck couldn't figure out the type
and therefore I'm not sure it's pure".  

Purity could just be silent in this case.

> 
> > @@ -5372,13 +5379,15 @@
> >  input/output) without taking an io__state (@pxref{Types}) as input and
> >  returning one as output, and do not make any changes to any data
> >  structure that will not be undone on backtracking (unless the data
> > -structure would be unreachable on backtracking).  The behaviour of other
> > -predicates is never affected by the invocation of pure predicates, nor
> > -is the behaviour of pure predicates ever affected by the invocation of
> > -other predicates.
> > +structure would be unreachable on backtracking).  The behaviour of pure
> > +predicates is never affected by the invocation of pure predicates.
> > +It is possible for the invocation of pure predicate to affect the
> > +behaviour of non-pure predicates and vice versa.
> 
> The last sentence sounds a little fishy to me. Surely the invocation of
> something pure can't affect the behaviour of anything.

See benchmarking.m for an example (Fergus thought of this one).

Also consider any example where you have a pure interface to a global
variable, and an impure predicate that accesses that variable (without it
being an imput argument).

BTW, this is why you need a cc_multi interface for benchmarking.
Any system where pure predicates can affect the behaviour of impure
predicates and where those impure preds present a "pure" interface later
on must be very careful.  It is important that the actions of the pure
interface are either linked through shared arguments with the pure
predicates that affect them, or given a cc_multi semantics.

Otherwise simply re-ordering the pure goals could easily affect the
behaviour of other pure goals.

> There's also a typo: s/of pure predicate/of pure predicates/

Will fix.

> 
> > +The compiler should issue a warning if the declared purity of a goal is
> > +less pure than its inferred purity.
> 
> I'm not sure that the language reference manual should talk about what warnings
> the compiler should be expected to produce. (Unless there is a precedent
> elsewhere in the manual that I wasn't aware of).

I'm open to suggestions on this one.  I mentioned it in the paper and
just pasted this in.  

There certainly is precendent -- consider the documention for pragma
obsolete.  This is a pragma whose purpose it to generate warnings.

> > +
> > +main -->
> > +	{ Y = get_counter },
> > +	{ Y(4, Z) },
> > +	print("X = "), 
> > +	print(Z), 
> > +	nl.
> > +
> > +:- impure pred get_counter(int::in, int::out) is det.
> > +
> > +:- pragma c_header_code("extern Integer counter;").
> > +:- pragma c_code("Integer counter = 0;").
> > +:- pragma c_code(get_counter(Y::in, X::out), will_not_call_mercury, "X = counter + Y;").
> > +
> 
> > ===================================================================
> > RCS file: purity_nonsense.err_exp
> > diff -N purity_nonsense.err_exp
> > --- /dev/null	Thu Mar  4 04:20:11 1999
> > +++ purity_nonsense.err_exp	Wed Nov 10 09:40:13 1999
> > @@ -0,0 +1,47 @@
> 
> This test case no longer looks right...

I'm not sure what you are talking about.  

If you are taling about purity_nonsense.m, then this is an old test
case.  It tests putting the words "impure" or "semipure" into rather
strange places.  The compiler should spit out lots of error messages.

The test is unchanged from the version that's been there for years.
I just moved it into a subdir.


I'll have a relative diff done soon.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't eveyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------