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

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Thu, 06 Jan 2011 12:26:10 +0100

Michael Hanus wrote:

*> 2. Non-linear patterns in function declarations: allow multiple
*

*> occurences
*

*> of a same variable in left-hand sides of function declarations.
*

*> Such occurrences are syntactic sugar for equational constraints,
*

*> i.e., a rule like "f x y (C x) = rhs" is syntactic sugar for
*

*> "f x y (C z) | x=:=z = rhs" where z is a fresh variable.
*

*> This extension avoids a restriction in Curry compared to logic
*

*> programming.
*

*> Moreover, the linearity condition does not make much sense
*

*> in the light of other useful extensions like functional patterns.
*

*> Finally, I don't see what is really gained by the linearity
*

*> restriction.
*

Thinking a bit more about it, I finally see a reason for keeping the

linearity restriction: Pattern matching in Curry (as in any other lazy

language) causes evaluation to head normal form, i.e., arguments are

evaluated just as far as necessary to make their shape equivalent to

the pattern. This is no longer the case with non-linear patterns. Each

argument in place of a variable which occurs more than once in a

pattern is evaluated to normal form. So while

(\x y -> success) (repeat 0) (repeat 0)

is fine,

(\x x -> success) (repeat 0) (repeat 0)

is not. Of course, the same is true when an explicit guard is used

(\x y -> x=:=y &> success) (repeat 0) (repeat 0)

but at least it is (hopefully) fairly obvious for the reader that

normal form evaluation occurs here.

There is also one point in your proposal that needs further

clarification: What about function rules with (constraint) guards? f x

x | g = e seems to have at least two possible translations: Either

sequential

f x y | x=:=y &> g = e

or concurrent

f x y | x=:=y & g = e

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Do Jan 06 2011 - 14:36:47 CET

Date: Thu, 06 Jan 2011 12:26:10 +0100

Michael Hanus wrote:

Thinking a bit more about it, I finally see a reason for keeping the

linearity restriction: Pattern matching in Curry (as in any other lazy

language) causes evaluation to head normal form, i.e., arguments are

evaluated just as far as necessary to make their shape equivalent to

the pattern. This is no longer the case with non-linear patterns. Each

argument in place of a variable which occurs more than once in a

pattern is evaluated to normal form. So while

(\x y -> success) (repeat 0) (repeat 0)

is fine,

(\x x -> success) (repeat 0) (repeat 0)

is not. Of course, the same is true when an explicit guard is used

(\x y -> x=:=y &> success) (repeat 0) (repeat 0)

but at least it is (hopefully) fairly obvious for the reader that

normal form evaluation occurs here.

There is also one point in your proposal that needs further

clarification: What about function rules with (constraint) guards? f x

x | g = e seems to have at least two possible translations: Either

sequential

f x y | x=:=y &> g = e

or concurrent

f x y | x=:=y & g = e

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry

Received on Do Jan 06 2011 - 14:36:47 CET

*
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:11 CEST
*