[mercury-users] Request for comments on this code

[Julien Fischer]

On Mon, 10 Jul 2006, Peter Schachte wrote:

> On Mon, Jul 10, 2006 at 05:00:51PM +1000, Julien Fischer wrote:
>> On Mon, 10 Jul 2006, Peter Schachte wrote:
>>> compiler couldn't reorder across && even to mode the clause correctly?
>>> If so, where are function calls in the clause head put, at the end of
>>> the clause or at the beginning?
>>
>> The compiler has to treat headvar unifications specially anyway.  Impure
>> goals in the body of a procedure cause a similar problem to the one you
>> have just described.
>>
>>> Or should && specify minimal
>>> reordering:  only enough reordering across && to get the code moded
>>> correctly?
>>
>> With the exception of reordering headvar unifications any other mode
>> reordering should result mode error - in fact it seems very similar
>> to how impure goals are handled now (minus the impure bit).
>
> But the impure bit is the important point:  impure code doesn't have a
> denotational semantics, so things like order of execution are part of
> the meaning of the code.  With && you're saying the code is pure and
> order doesn't matter, but just for operational reasons we want the
> code before the && to complete before starting the code after it.  But
> in that case, why is this so rigid?  Isn't && only advisory?

What would be the point of it if it were only advisory?

Actually, I think I'm wrong about having to handle it like impurity.
Function calls in the head of a clause can be handled in a straightfoward
fashion:

 	foo(bar(X, Y)::in, baz(W, P)::out) :-
 		Goal1 && Goal2.

becomes:

 	foo(H1, H2) :-
 		H1 = bar(X, Y),
 		H2 = baz(W, P),
 		( Goal1 && Goal2).

The compiler should be free to reorder the conjuncts in the outer conjunction.
It cannot however reorder Goal1 and Goal2 with respect to each other.

(Of course if Goal1 or Goal2 is impure then the usual handling of impurity
will need to kick in.)

> Why prohibit the compiler, for all times, from reordering the code to
> improve performance?  Eg, why forbid profiling-driven code improvement from
> reordering?

What do you mean by "for all times"?  We are only talking about it prohibiting
it from reordering in the presence of the && operator.

> And what about removing redundant computations?  Eg
>
> 	length(L, N) &&
> 	...
> 	length(L, Len),

I don't see why && should stop us removing redundant computations.
Since length is pure that would just become:

 	length(L, N) &&
 	...
 	Len = N,

Presumably the important part there is that `...' occurs after the initial
call to length.

> do we really need to traverse the list twice?  And if I write
>
> 	goal1,
> 	(goal2 && goal3),
> 	goal4
>
> can goal4 move before goal1?

I would say yes.  In this case what is important is that goal2 is executed
before goal3.

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at csse.unimelb.edu.au
administrative address: owner-mercury-users at csse.unimelb.edu.au
unsubscribe: Address: mercury-users-request at csse.unimelb.edu.au Message: unsubscribe
subscribe:   Address: mercury-users-request at csse.unimelb.edu.au Message: subscribe
--------------------------------------------------------------------------