- 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: Tue, 28 Oct 2014 17:17:13 +0100

On 10/27/2014 05:36 AM, lausgans_at_gmail.com wrote:

*> I’m interesting whether some syntax extensions are planned, exactly:
*

*>
*

*> 1. habitual disjunction, i.e. orC in Prelude in form of Cond1 orC Cond2 orC … instead of orC [Cond1, Cond2,...] resided in Constraint
*

I think this is a matter of taste. The prelude is already a big thing

and should contain frequently used operations, e.g., those which are

often used in the interactive top-level loop.

In programs, I think it is not a big effort to write

"import Constraint".

*> 2. fromBoolToSuccess (and vise versa?) and not operator for writing things like notC (fromBoolToSuccess (null lst)) instead of explicit null lst =:= False
*

Here you bring up an interesting point which should be discussed on

this list. Some people are not happy with the distinction of the

types "Success" and "Bool". Actually, I see these problems every time

I teach Curry to new students...

Sergio and I recently wrote a paper where it is proposed to drop

the type "Success" from Curry:

http://www.informatik.uni-kiel.de/~mh/papers/WFLP14_Success.html

Historically, Success was introduced as the Prolog-equivalent to

express unification, whereas Bool was taken from Haskell to express

sequential case distinctions. We think the language design of Curry

could be simplified by dropping the type Success and having only

one kind of equality (==) in the language. This would also simplify

your programming tasks, I guess.

The only tricky issue is to retain unification, if possible.

For instance, in the initial expression

x==[1,2] where x free

one would like to bind x to the list [1,2] instead of instantiating

x to all integer lists and produce False for all lists except [1,2].

However, this could be easily expressed by

solve (x==[1,2]) where x free

where "solve" is defined by

solve True = True

Due to this definition, the "False" results need not be computed

so that x could be bound [1,2]. This means that the old (=:=)

could be redefined by

x =:= y = solve (x == y)

As a consequence, no code duplication (like orC, andC,...) is necessary

for the Success type.

In order to play with this proposal, the recent (development) releases

of PAKCS and KiCS2 offer the operation solve (but still provide

the type Success and =:= for backward compatibility).

*> 3. matching of whole pattern and part of it in one construction, like in functional counterpart, i.e. (Var1_at_(SubVar1,SubVar2),Var2) =:= somefunction
*

This would mean that one uses pattern syntax also in expressions.

I think this could be confusing, in particular, since functional

patterns might have a different meaning. On the other hand,

it is not a big deal to transform this into a standard expression, e.g.,

(Var1,Var2) =:= somefunction &> Var1 =:= (SubVar1,SubVar2)

Best regards,

Michael

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Tue Oct 28 2014 - 17:17:59 CET

Date: Tue, 28 Oct 2014 17:17:13 +0100

On 10/27/2014 05:36 AM, lausgans_at_gmail.com wrote:

I think this is a matter of taste. The prelude is already a big thing

and should contain frequently used operations, e.g., those which are

often used in the interactive top-level loop.

In programs, I think it is not a big effort to write

"import Constraint".

Here you bring up an interesting point which should be discussed on

this list. Some people are not happy with the distinction of the

types "Success" and "Bool". Actually, I see these problems every time

I teach Curry to new students...

Sergio and I recently wrote a paper where it is proposed to drop

the type "Success" from Curry:

http://www.informatik.uni-kiel.de/~mh/papers/WFLP14_Success.html

Historically, Success was introduced as the Prolog-equivalent to

express unification, whereas Bool was taken from Haskell to express

sequential case distinctions. We think the language design of Curry

could be simplified by dropping the type Success and having only

one kind of equality (==) in the language. This would also simplify

your programming tasks, I guess.

The only tricky issue is to retain unification, if possible.

For instance, in the initial expression

x==[1,2] where x free

one would like to bind x to the list [1,2] instead of instantiating

x to all integer lists and produce False for all lists except [1,2].

However, this could be easily expressed by

solve (x==[1,2]) where x free

where "solve" is defined by

solve True = True

Due to this definition, the "False" results need not be computed

so that x could be bound [1,2]. This means that the old (=:=)

could be redefined by

x =:= y = solve (x == y)

As a consequence, no code duplication (like orC, andC,...) is necessary

for the Success type.

In order to play with this proposal, the recent (development) releases

of PAKCS and KiCS2 offer the operation solve (but still provide

the type Success and =:= for backward compatibility).

This would mean that one uses pattern syntax also in expressions.

I think this could be confusing, in particular, since functional

patterns might have a different meaning. On the other hand,

it is not a big deal to transform this into a standard expression, e.g.,

(Var1,Var2) =:= somefunction &> Var1 =:= (SubVar1,SubVar2)

Best regards,

Michael

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Tue Oct 28 2014 - 17:17:59 CET

*
This archive was generated by hypermail 2.3.0
: Mon Sep 23 2019 - 07:15:09 CEST
*