[m-dev.] Solver var initialisation and impure goals

[Ralph Becket]

I've made a change to the compiler so that when it tries to schedule an
impure goal, it first tries to schedule any delayed solver dependent
goals.  This means that instead of having to write something like

	foo(...) :-
			% Enclosing the solver goals in the quantifier
			% means all goals in the conjunction will be
			% schduled, by initialising X, if possible,
			% before schduling the impure goal.
		some [_] (
			solver_goal1(X),
			solver_goal2(X),
			solver_goal3(X)
		),
		impure do_something_with_X(X).

one can just write

	foo(...) :-
		solver_goal1(X),
		solver_goal2(X),
		solver_goal3(X),
		impure do_something_with_X(X).

However, there is a fly in the ointment.  Consider the following

	:- pred bar(t1::in, t2::out(any)) is det.

	bar(A, B) :-
		impure B = baz(A).

This is converted by the compiler into

	bar(HeadVar1, HeadVar2) :-
		A = HeadVar1,
		B = HeadVar2,
		impure B = baz(A).

During scheduling, the unification B = HeadVar2 will be delayed.
With my change, the compiler will try inserting initialisation
calls to schedule outstanding goals before scheduling the impure
goal.  This leads to

	bar(HeadVar1, HeadVar2) :-
		A = HeadVar1,
		initialise(B),
		B = HeadVar2,
		impure B = baz(A).

but now, of course, the impure unification goal is no longer an
assignment, but an implied mode!  This can change what would
appear to be det code into semidet code.  In fact, the above
doesn't compile with my change; it has to be rewritten as

	bar(A, B) :-
		( if   impure B = baz(A)
		  then true
		  else throw("shouldn't be here")
		).

This is not just ugly, it's less efficient: implicitly initialising B
and then adding an implied unification is going to be much more
expensive than just doing an assignment.

Has anyone any ideas as to how to get around this one?  I'm starting
to think that the right way to deal with this stuff is to move to 
constraint based mode analysis.  Hacking around in the current mode
analysis code is like swimming through treacle.


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