Re: Language changes: Committed choice

From: Herbert Kuchen <kuchen_at_uni-muenster.de>
Date: Tue, 27 Oct 1998 12:51:22 +0000

Dear Frank,

Frank Steiner wrote:

> Dear Wolfgang,
>
> first of all there is indeed a lazy version of merge, i.e.
>
> merge l1 l2 =
> choice {l1=:=[]} -> l2
> {l2=:=[]} -> l1
> {e=:=head l1} -> e:merge (tail l1) l2 where e free
> {e=:=head l2} -> e:merge l1 (tail l2) where e free
>

First of all, your version of merge is (lazier, but) NOT lazy, since
itcompletely evaluates the first element e of the "selected list".
If e.g. lists of lists are merged, the resulting behavior is not lazy.
Of course, you could come up with yet another version of
merge which handles lists of lists of e.g. basic values lazily.
This would not be very elegant and it would not help, if
you want to merge lists of lists of lists lazily ...

If we assume that we are interested in a lazy polymorphic
version of merge, then the present syntax does not
adequately enable this.

> You also must consider, that your new choice eval annotation could
> only be an additional construct and mustn't replace the choice
> construct as it is now, because the actual choice construct is
> more expressive. Since arbitrary constraints are allowed as guards one
> could write sth. like
>
> test func1 func2 arg = choice {func1 arg} -> True
> {func2 arg} -> False
>
> where func1 and func2 have type a -> Constraint.
> This is not expressible with the choice eval annotation.

You are right that providing committed choice as a third evaluationannotation
is less powerful than the present concept. The question
is whether you really need to have committed choice based on arbitrary
constraints in practical applications. I doubt that. In fact, I think
that typical programs use committed choice at very few places
and that all of them can be handled by the approach using evaluation
annotations. In most (if not all) cases, it will be possible to just
replace func1 and func2 by func1' and func2' of type a -> Bool
and the boolean result could be used for "pattern matching" (with
annotation "choice").

There should definitely be only one choice concept in the language!!!
We should not confuse the user by to many (similar) concepts.
And here I think it is more important to have a concept that enables the
(easy) combination of laziness and committed choice than to
have committed choice based on arbitrary constraints.


> max x y = choice {x>=y = True} = x
> {x<=y = True} = y
>

max is not really a counter example, since it can easily beexpressed in another
way (and even without committed choice at all).
What about:

max x y = f (x>=y) (x<=y) x y

f eval choice
f True c x y = x
f c True x y = y

Best regards,

Herbert
Received on Di Okt 27 1998 - 12:59:00 CET