- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Frank Steiner <steiner_at_informatik.rwth-aachen.de>

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

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

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

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 Tue Oct 27 1998 - 11:46:00 CET

*
This archive was generated by hypermail 2.3.0
: Mon Sep 23 2019 - 07:15:04 CEST
*