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).
Regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Dez 03 2004 - 12:31:07 CET