Denys Duchier wrote:
> lI never said that that you were suggesting it (the use of `you' was
> intended to indicate an unspecified individual, rather than just you
> specifically). _One_ should not put a control variable in the guard
> of a `cond'. ok?
That sounds better :-)
>
> Apropos your suggested implementation, it has the following 3 problems:
>
> * it duplicates constraints and this is undesirable
I think it depends on the fact of getting rid of useless propagators.
>
>
> * it doesn't actually do what you set out to do, which was to get rid
> of sibling guards once you have decided for one of them. In the
> direction cond->or things are ok, but in the direction or->cond,
> they are not. Suppose you explicitly decide C=2, this does not
> cause the cond to commit to the 2nd alternative... and this brings
> us to the last and damning problem:
This is not totally true. C=2 will cause the other sibling spaces to fail and
the local space where C=2 is to merge with the parent space. In this way,
there would be enough information in the store to entail the constraint
associated with C=2.
However, I acknowledge that there are some estrange cases where
P
P->Q
------
Q
does not hold.
For instance:
not X=1 end
cond not X=1 end then {Browse ok} end
>
>
> * it has confluence problems. This is best explained with an example
> where there are several identical guards. Your implementation would
> look someting like this
>
> thread
> cond X=1 then C=0
> [] X=1 then C=1
> end
> end
> thread
> or C=0 X=1
> [] C=1 X=1
> end
> end
>
> Now suppose that you explicitly decide C=1. The `or' commits to the
> second clause and thus imposes X=1. Now the `cond' wakes up and
> discovers that at least one of its guards is entailed, which one it
> discovers is impredictable as it depends on concurrency. Suppose,
> it first discovers that its first guard is entailed, then it commits
> to that and attempts to impose C=0, which causes a failure. If it
> had discovered entailment of its second guard first, it would have
> imposed C=1 which succeeds.
>
Agree, but I wonder whether this indeed happens in a real scenario....
Luis
-- Catholic University of Louvain Department of Computing Science and Engineering Place Sainte Barbe, 2 B-1348 Louvain-la-Neuve, Belgium Phone: (++32) (10) 47 90 13 Fax: (++32) (10) 45 03 45 E-mail: luque@info.ucl.ac.be- Please send submissions to users@mozart-oz.org and administriva mail to users-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.