Dear Colleagues,
I'd like to propose a simplification of the definition of Curry
which came to my mind after using Curry in a larger software
project.
Proposal:
=========
Do not allow program rules with multiple guards of type "Success",
i.e., the following program rule is no longer valid:
f x | x=:=0 = 0 --(1)
| x=:=1 = 0
Instead, it should be written as
f x | x=:=0 = 0 --(2)
f x | x=:=1 = 0
Rationale:
==========
Although the short notation with multiple constraint guards seems
convenient, it is seldom used and causes a lot of confusion.
For compatibility with Haskell, one can write in a Curry program
multiple guards with Boolean conditions, e.g.,
sig x | x==0 = 0 --(3)
| x>0 = 1
| otherwise = -1
which is interpreted as a nested if-then-else:
sig x = if x==0 then 0 else if x>0 then 1 else -1
Since constraints do not provide for negation but can only be
checked for satisfiability, the Curry report defines the above
two definitions of f as equivalent, i.e., multiple constraint
guards are always interpreted as a non-deterministic definition
(i.e., both rules defining f are applicable if their constraints
are satisfiable). This is clear from the syntax in (2) (since
there are two rules and all rules are independent in Curry)
but not from the syntax in (1), since (1) looks "more sequential".
I have made the experience that this causes sometimes confusion,
if one starts with multiple Boolean guards as in (3) but later
decides to use more powerful constraints as guards. Thus, a change
in the type of constraints can cause a change in its operational behavior.
These problems can be avoided by requiring that multiple guards
are only allowed if they are all of Boolean type.
In this case they are interpreted as a sequential testing
of conditions.
I have looked at many Curry programs and I have the feeling
that multiple guards are almost always used with Boolean constraints.
Thus, this change should have no influence on most programs.
Please let me know if you have other experiences or arguments
in favor of the current definition. Otherwise, I'll introduce
this change in the next update of the Curry report.
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Apr 07 2003 - 16:18:32 CEST