Re: Committed Choice (Was: Summary of changes)

From: Michael Hanus <>
Date: Fri, 03 Dec 2004 12:19:49 +0100

Wolfgang Lux wrote:
> There is a subtle problem here. Which variables are considered
> local and may be bound during the evaluation of the constraint
> expression? I guess you mean that only variables which are
> introduced during the evaluation of the constraints may be bound
> (at least this is the only reasonable definition of local I can
> imagine).

No, I mean all variables that are local to the argument of commit,
i.e., that are introduced by a let, as the x in your example

> coin 0 = success
> coin 1 = success
> oneCoin = commit [let x free in (coin x,x)]
> will not work. At least it would not work with MCC because oneCoin
> is transformed into let x free in commit [(coin x,x)], for which
> the variable shared between the constraint and the expression is
> obviously defined before commit is evaluated. Note that the

As German already noticed, I don't see why this transformation
is necessary.

> normalization in [AH+02] will transform oneCoin in a similar way.

German already answered it, but I have one correction. The
translation is

oneCoin = let y = let x free in let z = coin x in (z,x)
           in commit y

> Since this is quite complicated, I would suggest providing some special
> syntax for committed choice, which is similar to that of case
> expressions.
> Expr ::= ... | ChoiceExpr
> ChoiceExpr ::= choice Expr of { ChoiceBranch_1 ; ... ;
> ChoiceBranch_n }
> ChoiceBranch :: Expr [ | Expr ] -> Expr [ where LocalDefs ]
> With this syntax oneCoin and merge can be defined as follows:
> oneCoin = choice undefined of { _ | coin x -> x where x free }
> merge l1 l2 =
> choice (l1,l2) of
> ([],l2) -> l2
> (l1,[]) -> l1
> (e:r,l2) -> e : merge r l2
> (l1,e:r) -> e : merge l1 r

Although I think this syntax is quite nice (and similar to other
commit constructs, like in Oz), I am reluctant to introduce
new syntax for things that are seldom used since the recent
discussion have shown that one can often replace them by
other primitives.

> > BTW, as I already mentioned, I don't think that the primitives
> > ensure... will be often use in application programs.
> > In my applications it is sufficient to drop all evaluation
> > annotations and add ensure... calls only in the Port library
> > (where suspension is really necessary).
> Don't forget appendix A.6 of the report :-)

Yes, but the implementation of concurrent objects will
be usually applied in combination with ports (A.6 is too simple
since it allows only one client).



curry mailing list
Received on Fr Dez 03 2004 - 12:31:07 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:07 CEST