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

From: Steffen Mazanek <steffen.mazanek_at_unibw.de>

Date: Wed, 05 Jan 2011 12:46:51 +0100

Dear All,

I am not a Curry language expert and, thus, not aware of all the

implications of these proposals. For my practical applications (most

importantly the grappa library

http://www.unibw.de/steffen.mazanek/forschung/grappa), both extensions

would be very, very useful! The code would be even more concise! In

particular the don't-care free variables would be great.

Cheers,

Steffen

2011/1/5 Michael Hanus <mh_at_informatik.uni-kiel.de>:

*> Dear Colleagues,
*

*>
*

*> I'd like to propose two slight syntax extensions to the current definition
*

*> of Curry that I found useful to make programs more readable
*

*> from my practical experiences.
*

*>
*

*> 1. Anonymous free variables: allow anonymous variables of the form "_"
*

*> (underscore) in arbitrary expressions. Currently, anonymous variables
*

*> are only allowed in patterns but not as free variables in right-hand
*

*> sides or condition of rules. This has the drawback that they
*

*> must be explicitly declared or one has to use the Prelude
*

*> operation "unknown". Both is not nicely readable if one has
*

*> several unknown arguments to some operation f:
*

*> let a,b,c,d,e free in f x a b c d e
*

*> or
*

*> f x unknown unknown unknown unknown unknown
*

*> With the proposed extension, one can simply write "f x _ _ _ _ _"
*

*> Thus, an occurrence of "_" in an expression is syntactic sugar
*

*> for "let x free in x" (or the operation Prelude.unknown).
*

*>
*

*> 2. Non-linear patterns in function declarations: allow multiple occurences
*

*> of a same variable in left-hand sides of function declarations.
*

*> Such occurrences are syntactic sugar for equational constraints,
*

*> i.e., a rule like "f x y (C x) = rhs" is syntactic sugar for
*

*> "f x y (C z) | x=:=z = rhs" where z is a fresh variable.
*

*> This extension avoids a restriction in Curry compared to logic programming.
*

*> Moreover, the linearity condition does not make much sense
*

*> in the light of other useful extensions like functional patterns.
*

*> Finally, I don't see what is really gained by the linearity restriction.
*

*>
*

*> I am interested to get some feedback on this proposal.
*

*>
*

*> Best regards,
*

*>
*

*> Michael
*

*> _______________________________________________
*

*> curry mailing list
*

*> curry_at_lists.RWTH-Aachen.DE
*

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

*>
*

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Mi Jan 05 2011 - 13:50:41 CET

Date: Wed, 05 Jan 2011 12:46:51 +0100

Dear All,

I am not a Curry language expert and, thus, not aware of all the

implications of these proposals. For my practical applications (most

importantly the grappa library

http://www.unibw.de/steffen.mazanek/forschung/grappa), both extensions

would be very, very useful! The code would be even more concise! In

particular the don't-care free variables would be great.

Cheers,

Steffen

2011/1/5 Michael Hanus <mh_at_informatik.uni-kiel.de>:

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Mi Jan 05 2011 - 13:50:41 CET

*
This archive was generated by hypermail 2.3.0
: Do Jan 20 2022 - 07:15:04 CET
*