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 Mi Jan 05 2011 - 15:09:05 CET