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

From: Michael Hanus <hanus_at_informatik.rwth-aachen.de>

Date: Thu, 25 Nov 1999 11:08:46 +0100 (MET)

Dear Colleagues,

during the last FLOPS conference in Tsukuba, there was a meeting

with Sergio Antoy, Herbert Kuchen, Wolfgang Lux and me where

we discussed a few changes w.r.t. the current definition

of Curry. I summarize the proposed changes below.

1. "pragma optmatch"

====================

Currently, the default definition of pattern matching

is left-to-right in order to be compatible with Haskell.

However, since it is known that this pattern matching is

not optimal and can be easily improved, there is the

pragma "optmatch" to enable the better pattern matching.

To see the difference, look at the following example:

g 0 [] = 0

g _ (x:_) = x

h x = h x

Since Haskell does pattern matching from left to right,

it will not terminate for the expression "(g (h 0) [1])".

With the pragma optmatch, Curry will compute the value "1"

for the same expression. One might think that this example

is artificial but there is another drawback of left-to-right

pattern matching shown by this example: although the program

is inductively sequential (which means that all evaluations of

ground terms can be deterministic), left-to-right pattern matching

introduces a disjunction (or-node in the definitional trees)

so that computations becomes non-deterministic. This property

has really negative consequences since, if computations becomes

non-deterministic, one needs to encapsulated them between I/O

operations where there is really no need to do it. Although

one can always add the pragma optmatch to avoid it, the

default left-to-right pattern matching is really a pitfall:

I and also some other colleagues spent a lot of time for

debugging (mainly in distributed applications written in Curry,

which is non-trivial!) where at the end the only reason was

the non-optimal default pattern matching.

Therefore, here is the proposal:

Omit the pragma optmatch and make it as default!

Of course, this is no longer compatible with Haskell, but the

only incompatibilities are:

- Curry programs terminate and compute a result where Haskell

does not terminate: we think this is a nice behavior and which does

not cause problems.

- Curry programs perform evaluations steps in a different order

than Haskell: since the final results are identical (if Haskell

terminates), this seems also not to be a problem.

2. Name of datatype "Constraint"

================================

Mario Rodriguez remarked that the name of the datatype "Constraint"

is misleading, since its elements are not constraints but it denotes

a domain containing only one truth value as the single non-trivial

element (in contrast to "Bool" which contains two truth values),

i.e., negation of constraints is not directly defined but must

be supported by a constraint solver (e.g., disequality constraints

in Toy). Thus, what is traditionally considered as a constraint

is an element of the function domain (t1->...->tn->Constraint),

e.g., (=:=)::a->a->Constraint is the standard equational constraint.

To avoid thess misunderstandings and make the notions clearer,

we suggest to change the name "Constraint" into a name related

to a domain with only a positive truth value. Proposals are

- Success (since "success" is currently the corresponding function)

- Valid (for validity)

- Truth (for indicating the this domains can only express truth)

If we adapt e.g. "Success", then one can say that a "constraint"

is a function with result type "Success", which avoids some of the

misunderstandings with the current names.

3. Literate programming

=======================

After developing more applications and libraries for Curry,

some of us had the feeling that the literate programming style

should be added to Curry for better documentation. The literate

programming style encourages the use of comments for the

documentation of programs since in this style comments

are the default case. Non-comment lines containing program code

must start with ">" followed by a blank. To distinguish

literate programs from standard programs, they must be stored

in files with the extension ".lcurry" (instead of ".curry").

The implementation is not a big deal, since one can easily

write a shell script (thanks Sergio!) to translate .lcurry programs

into .curry programs.

That's all for the moment. Comments are welcome!

Best regards,

Michael

Received on Do Nov 25 1999 - 11:10:57 CET

Date: Thu, 25 Nov 1999 11:08:46 +0100 (MET)

Dear Colleagues,

during the last FLOPS conference in Tsukuba, there was a meeting

with Sergio Antoy, Herbert Kuchen, Wolfgang Lux and me where

we discussed a few changes w.r.t. the current definition

of Curry. I summarize the proposed changes below.

1. "pragma optmatch"

====================

Currently, the default definition of pattern matching

is left-to-right in order to be compatible with Haskell.

However, since it is known that this pattern matching is

not optimal and can be easily improved, there is the

pragma "optmatch" to enable the better pattern matching.

To see the difference, look at the following example:

g 0 [] = 0

g _ (x:_) = x

h x = h x

Since Haskell does pattern matching from left to right,

it will not terminate for the expression "(g (h 0) [1])".

With the pragma optmatch, Curry will compute the value "1"

for the same expression. One might think that this example

is artificial but there is another drawback of left-to-right

pattern matching shown by this example: although the program

is inductively sequential (which means that all evaluations of

ground terms can be deterministic), left-to-right pattern matching

introduces a disjunction (or-node in the definitional trees)

so that computations becomes non-deterministic. This property

has really negative consequences since, if computations becomes

non-deterministic, one needs to encapsulated them between I/O

operations where there is really no need to do it. Although

one can always add the pragma optmatch to avoid it, the

default left-to-right pattern matching is really a pitfall:

I and also some other colleagues spent a lot of time for

debugging (mainly in distributed applications written in Curry,

which is non-trivial!) where at the end the only reason was

the non-optimal default pattern matching.

Therefore, here is the proposal:

Omit the pragma optmatch and make it as default!

Of course, this is no longer compatible with Haskell, but the

only incompatibilities are:

- Curry programs terminate and compute a result where Haskell

does not terminate: we think this is a nice behavior and which does

not cause problems.

- Curry programs perform evaluations steps in a different order

than Haskell: since the final results are identical (if Haskell

terminates), this seems also not to be a problem.

2. Name of datatype "Constraint"

================================

Mario Rodriguez remarked that the name of the datatype "Constraint"

is misleading, since its elements are not constraints but it denotes

a domain containing only one truth value as the single non-trivial

element (in contrast to "Bool" which contains two truth values),

i.e., negation of constraints is not directly defined but must

be supported by a constraint solver (e.g., disequality constraints

in Toy). Thus, what is traditionally considered as a constraint

is an element of the function domain (t1->...->tn->Constraint),

e.g., (=:=)::a->a->Constraint is the standard equational constraint.

To avoid thess misunderstandings and make the notions clearer,

we suggest to change the name "Constraint" into a name related

to a domain with only a positive truth value. Proposals are

- Success (since "success" is currently the corresponding function)

- Valid (for validity)

- Truth (for indicating the this domains can only express truth)

If we adapt e.g. "Success", then one can say that a "constraint"

is a function with result type "Success", which avoids some of the

misunderstandings with the current names.

3. Literate programming

=======================

After developing more applications and libraries for Curry,

some of us had the feeling that the literate programming style

should be added to Curry for better documentation. The literate

programming style encourages the use of comments for the

documentation of programs since in this style comments

are the default case. Non-comment lines containing program code

must start with ">" followed by a blank. To distinguish

literate programs from standard programs, they must be stored

in files with the extension ".lcurry" (instead of ".curry").

The implementation is not a big deal, since one can easily

write a shell script (thanks Sergio!) to translate .lcurry programs

into .curry programs.

That's all for the moment. Comments are welcome!

Best regards,

Michael

Received on Do Nov 25 1999 - 11:10:57 CET

*
This archive was generated by hypermail 2.3.0
: So Jan 26 2020 - 07:15:07 CET
*