[m-dev.] Doco bug?
Zoltan Somogyi
zs at cs.mu.OZ.AU
Fri Dec 29 16:17:31 AEDT 2000
On 29-Dec-2000, Thomas Conway <conway at cs.mu.OZ.AU> wrote:
> % Mercury has two constructs that make it possible for a variable to be needed
> % on some computation paths but not others: switches and if-then-elses.
>
> Why not disjunctions?
> For example:
> ...,
> s(W::out),
> p(X::out),
> (
> q(X)
> ;
> r(W)
> ).
The problem is that moving p(X) into the first disjunct doesn't remove
it from computation paths that go through the second disjunct, since you
can only get to the second disjunct by executing the first and then failing.
(The failure may be inside q(X) or in the code executed after the disjunction,
which may or may not be in the current procedure.)
Moving s(W) into the second disjunct only helps if the second disjunct
doesn't get executed. However, for model_non conjunctions the second disjunct
*will* be executed even if the first disjuct succeeds, unless a surrounding
commit cuts off that line of search.
This is why the payoff is smaller for disjunctions than for switches or
if-then-elses. The cost in programming complexity is also unfavorable.
Consider code like this:
s(W::out),
p(X::out),
(
q1(X)
;
q2(X, W)
;
r(W)
).
With a switch, you could simply move p(X) into the switch arms where it is
needed. With a disjunction, doing likewise would be a pessimization, because
it would in many cases force p(X) to be evaluated twice. You would have to do
something like
s(W::out),
(
p(X::out),
(
q1(X)
;
q2(X, W)
;
;
r(W)
).
And then what do you do with s(W)?
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
--------------------------------------------------------------------------
More information about the developers
mailing list