Re: Language changes: Committed choice

From: Frank Steiner <>
Date: Tue, 27 Oct 1998 11:46:36 +0100

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

With that definition


results in


But of course you are right that in general it would be easier
in some cases to have pattern matching instead of solving
strict equalities. So I think your proposal could be helpful in
some cases, although I'm not sure if there are examples where
you choice eval annotation is more expressive than the actual choice

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. As concrete
example you might also consider the max function defined by choice:

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

A similar definition with the eval annotation shouldn't be possible.

So the question is if it would be good to have two different choice
constructs/annotations in the language. For taking this decision it
would perhaps be helpful if we could find an example using the choice
eval annotation which cannot be expressed (with the same functionality)
with the choice construct, i.e. where pattern matching cannot be
simulated with the actual choice construct. I did not think about such
an example yet, perhaps you or someone else has one in mind.

If it would really be neccessary to add such a new pattern matching choice
than it might be easier to add a special anotation to the existing
choice so that at the end we still have only one construct for comitted
choice. Perhaps sth like

  choice {l <- r} -> ...

instead of

  choice {l = r} -> ...

could be used to indicate that pattern matching instead of strict equality
should be performed. That is just a "quick shot" idea which I haven't
thought about very well. It could be a problem with the type of the guards,
but as mentioned, this is just a first quick proposal. I would be interested
in other opinions about it.

Best regards,


Dipl.-Inform. Frank Steiner   
  Lehrstuhl fuer Informatik II
  RWTH Aachen, D-52056 Aachen
  Phone:  +49 241 80-21241
  Fax:    +49 241 8888-217
Received on Di Okt 27 1998 - 11:46:00 CET

This archive was generated by hypermail 2.3.0 : Sa Feb 24 2024 - 07:15:05 CET