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

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Tue, 02 Nov 2004 18:28:10 +0100

Michael Hanus wrote:

*> The first one is related to the introduction of free variables.
*

*> The current language definition (Curry Report, C.3) requires
*

*> that in an expression of the form
*

*>
*

*> let x free in e
*

*>
*

*> e must be of type "Success" (1).
*

*>
*

*> [...]
*

*>
*

*> Thus, I propose to drop the restriction (2).
*

*> This would also make the application of let and where
*

*> "more equivalent".
*

I wholeheartedly agree to this proposal. (I did object against breaking

the symmetry between let and where right from the start, so this

probably

comes at no surprise to you.)

*> The second restriction concerns the sequential conjunction
*

*> of constraints, which is currently defined as
*

*>
*

*> (&>) :: Success -> Success -> Success
*

*> c &> x | c = x
*

*>
*

*> in the prelude.
*

*>
*

*> [...]
*

*>
*

*> Since such a guard function is quite useful, I propose
*

*> to generalize the type of (&>) to
*

*>
*

*> (&>) :: Success -> a -> a
*

*>
*

*> so that it is a general function to establish new constraints
*

*> during arbitrary computations.
*

In MCC's Success library module, I have introduced two operators

(==>) :: Success -> a -> a

and

(<==) :: a -> Success -> a

for exactly the same reason quite a while ago. (I have chosen (<==)

as it resembles Toy's guard notation.) However, it turns out that I

use these functions vary sparingly. For one, MCC supports guards in

case expressions, which covers most of the cases where I was using

these operators. And second, it turns out that the prelude already

contains an even more general operator, which does achieve exactly the

same effect. Instead of guard (x=:=1) (2+x), you could as well write

x=:=1 `seq` 2+x

Regards

Wolfgang

P.S.: I have another proposal for a minor change in the report

regarding evaluation annotations. At present, the report says

(p. 14 in Sect. 3)

A function can be explicitly annotated as rigid. If an

explicit annotation is not provided by the user, a default

strategy is used: functions with the result type ``IO ...''

are rigid and all other defined functions are flexible.

Functions with a polymorphic result type (like the identity)

are considered as flexible, although they can be applied like

a function with result type ``IO ...'' in a particular context.

I have been a proponent of the IO exception because flexible

evaluation in an IO context does not make sense. However, with

hindsight, I concede that this was ill-advised because we have

no concurrency at the level of the IO monad and therefore the

choice is simply between failing either due to a suspending

computation or a non-deterministic computation.

Moreover, the quote from the report is utterly misleading.

For instance, mapIO has result type IO [b], but its prelude

implementation is nevertheless flexible. And to add to the

confusion, sequenceIO is rigid whereas sequenceIO_ is not!

Therefore, I propose to simplify the default strategy so as

to make all functions flexible by default and replace the

quoted sentences by:

A function can be explicitly annotated as rigid. If an

explicit annotation is not provided by the user, it is

flexible.

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Wed Nov 03 2004 - 08:47:41 CET

Date: Tue, 02 Nov 2004 18:28:10 +0100

Michael Hanus wrote:

I wholeheartedly agree to this proposal. (I did object against breaking

the symmetry between let and where right from the start, so this

probably

comes at no surprise to you.)

In MCC's Success library module, I have introduced two operators

(==>) :: Success -> a -> a

and

(<==) :: a -> Success -> a

for exactly the same reason quite a while ago. (I have chosen (<==)

as it resembles Toy's guard notation.) However, it turns out that I

use these functions vary sparingly. For one, MCC supports guards in

case expressions, which covers most of the cases where I was using

these operators. And second, it turns out that the prelude already

contains an even more general operator, which does achieve exactly the

same effect. Instead of guard (x=:=1) (2+x), you could as well write

x=:=1 `seq` 2+x

Regards

Wolfgang

P.S.: I have another proposal for a minor change in the report

regarding evaluation annotations. At present, the report says

(p. 14 in Sect. 3)

A function can be explicitly annotated as rigid. If an

explicit annotation is not provided by the user, a default

strategy is used: functions with the result type ``IO ...''

are rigid and all other defined functions are flexible.

Functions with a polymorphic result type (like the identity)

are considered as flexible, although they can be applied like

a function with result type ``IO ...'' in a particular context.

I have been a proponent of the IO exception because flexible

evaluation in an IO context does not make sense. However, with

hindsight, I concede that this was ill-advised because we have

no concurrency at the level of the IO monad and therefore the

choice is simply between failing either due to a suspending

computation or a non-deterministic computation.

Moreover, the quote from the report is utterly misleading.

For instance, mapIO has result type IO [b], but its prelude

implementation is nevertheless flexible. And to add to the

confusion, sequenceIO is rigid whereas sequenceIO_ is not!

Therefore, I propose to simplify the default strategy so as

to make all functions flexible by default and replace the

quoted sentences by:

A function can be explicitly annotated as rigid. If an

explicit annotation is not provided by the user, it is

flexible.

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Wed Nov 03 2004 - 08:47:41 CET

*
This archive was generated by hypermail 2.3.0
: Fri Sep 20 2019 - 07:15:05 CEST
*