Re: Proposal: Syntax extension

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

This archive was generated by hypermail 2.3.0 : Do Feb 01 2024 - 07:15:10 CET