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