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

From: Wolfgang Lux <wlux_at_uni-muenster.de>

Date: Wed, 05 Jan 2011 14:58:25 +0100

Michael Hanus wrote:

*> 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).
*

Nice to see that somebody else considers this useful, too. I added

this as an extension to MCC some time ago, but never got round to

making a proposal...

*> 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 understand the motivation for this proposal, but I feel somewhat

uneasy about the fact that Curry will now have two different kinds of

patterns: Patterns in function heads which may be non-linear and

patterns in case expressions which must be linear (btw, what about

patterns on the left hand side of local declarations, let (x,x) = e

in ...?).

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

I also have a third proposal: Flexible case (aka fcase) expressions.

One of the advantages of an integrated functional logic language

compared to logic languages is that we have nested expressions and can

avoid new auxiliary declarations for functions that are used in just

one place. However, this is currently not possible for flexible

pattern matching. Hence, I suggest adding a new kind of expression

fcase <Expression> of { <Alternative1>; ...; <AlternativeN> } (n

* >= 1)
*

The semantics of fcase expressions is given by a simple translation

fcase e of { t1 | gd11 -> e11; ...; tn | gdn -> en }

~~>

let f t1 | gd1 = e1; ...; f tn | gdn = en in f e

i.e., no fall through behavior as in (rigid) case expressions.

Obviously, by this translation an fcase expression can evaluate to

multiple results, e.g., fcase _ of { _ -> False; _ -> True } would be

just a slightly complex way to write the expression False ? True. I

guess, its needless to say that MCC implements fcase expressions

already.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Wed Jan 05 2011 - 15:09:05 CET

Date: Wed, 05 Jan 2011 14:58:25 +0100

Michael Hanus wrote:

Nice to see that somebody else considers this useful, too. I added

this as an extension to MCC some time ago, but never got round to

making a proposal...

I understand the motivation for this proposal, but I feel somewhat

uneasy about the fact that Curry will now have two different kinds of

patterns: Patterns in function heads which may be non-linear and

patterns in case expressions which must be linear (btw, what about

patterns on the left hand side of local declarations, let (x,x) = e

in ...?).

I also have a third proposal: Flexible case (aka fcase) expressions.

One of the advantages of an integrated functional logic language

compared to logic languages is that we have nested expressions and can

avoid new auxiliary declarations for functions that are used in just

one place. However, this is currently not possible for flexible

pattern matching. Hence, I suggest adding a new kind of expression

fcase <Expression> of { <Alternative1>; ...; <AlternativeN> } (n

The semantics of fcase expressions is given by a simple translation

fcase e of { t1 | gd11 -> e11; ...; tn | gdn -> en }

~~>

let f t1 | gd1 = e1; ...; f tn | gdn = en in f e

i.e., no fall through behavior as in (rigid) case expressions.

Obviously, by this translation an fcase expression can evaluate to

multiple results, e.g., fcase _ of { _ -> False; _ -> True } would be

just a slightly complex way to write the expression False ? True. I

guess, its needless to say that MCC implements fcase expressions

already.

Regards

Wolfgang

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Wed Jan 05 2011 - 15:09:05 CET

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