[m-dev.] Impurity syntax

[Zoltan Somogyi]

On 13-Aug-2004, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> LIGHTER WEIGHT SYNTAX TO REPLACE IMPURITY
> (PROBABLY NOT REALLY NEEDED)

What you are proposing is a minor variant of something that has been
proposed before, as extended DCGs. We eventually decided to use
state variable syntax instead, a fact I wouldn't have expected
to have to remind you of :-)

It seems that all your proposal does that state variable notation
doesn't already give you is to allow a solver predicate to have
different arities inside and outside its defining module.

To do that, what you want is something like

:- pred p(int::in, int::out) is det.

in the interface of the solver module, and

:- pred_extension p(solverstate::di, solverstate::uo) is det.

p(I, O, !S) :-
	...

in its implementation section, with the compiler transforming this to

exported_p(I, O) :-
	semipure pickup_solver_state_from_global_var(S0),
	p(I, O, S0, S),
	impure store_solver_state_to_global_var(S).

You can make the use of pred_extension imply promise_pure on both exported_p
and p, at least optionally.

> (4) Two calls that change the same state item cannot be reordered with
> respect to one another.

Peter says what you actually mean here is that two impure calls to affect
different parts of the state *should* be reorderably with respect to each
other. That is fine; it would mean replacing the compiler's current notion of
"impure" with a more complex one "impure for these resources". I would propose
that the resources be identified with state variables, and the markers be
attached to the relevant goals during state variable expansion.

> (5) The state items have no physical realisation; they exist purely as
> an ordering mechanism.  The `changes foo' annotation is tantamount to
> adding an implicit (in, out) pair of arguments to a predicate and
> threading a state variable throughout the body of the predicate to calls
> to predicates that change `foo'.

This is a missing optimization. I once tried to do this I/O states, but
realized that doing a proper job requires handling code that does things
like put I/O states into terms. (You don't have to handle them optimally
or even very well, but you have to handle them.)

Having a piece of syntax that says "ever call in this scope that calls an
impure predicate is implicitly marked impure, and similarly for semipure"
would also be a good idea for constraint solvers.

At my request, pjs is calling a meeting to discuss these issues in person.

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