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
take(10,merge(repeat(1),repeat(2))).
results in
[1,2,1,2,1,2,1,2,1,2].
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
construct.
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,
Frank
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dipl.-Inform. Frank Steiner
Lehrstuhl fuer Informatik II
RWTH Aachen, D-52056 Aachen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phone: +49 241 80-21241
Fax: +49 241 8888-217
mailto: steiner_at_informatik.rwth-aachen.de
http://www-i2.informatik.rwth-aachen.de/steiner/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received on Di Okt 27 1998 - 11:46:00 CET