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

From: Michael Hanus <mh_at_informatik.uni-kiel.de>

Date: Mon, 07 Apr 2003 16:05:04 +0200

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

Date: Mon, 07 Apr 2003 16:05:04 +0200

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

*
This archive was generated by hypermail 2.3.0
: Sa Jul 24 2021 - 07:15:03 CEST
*