- 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: Thu, 06 Jan 2011 09:42:51 +0100

Wolfgang Lux wrote:

*> 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 thought about it but I prefer to make smaller extensions.

In principle, one could also allow non-linear patterns

in local declarations by translating "let (x,x) = e in e'"

into "let (x,y) = e in x=:=y &> e'" and similarly for case

expression where one can put "x==y" into the guards.

On the other hand, I think that functional patterns

(see http://www.informatik.uni-kiel.de/~mh/papers/LOPSTR05.html )

are a quite useful language extension. If one adds this

to Curry (as done in PAKCS), it makes sense to allow

different kinds of patterns in function declarations

and case/let expressions. Therefore, I have no problem

to make this distinction.

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

I think this is interesting and I am in favor of it.

This has also the advantage that intermediate languages

like FlatCurry (which is based on an fcase/case distinction)

do not introduce syntactic constructs that are not present

in the source language.

Best regards,

Michael

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Do Jan 06 2011 - 09:49:01 CET

Date: Thu, 06 Jan 2011 09:42:51 +0100

Wolfgang Lux wrote:

I also thought about it but I prefer to make smaller extensions.

In principle, one could also allow non-linear patterns

in local declarations by translating "let (x,x) = e in e'"

into "let (x,y) = e in x=:=y &> e'" and similarly for case

expression where one can put "x==y" into the guards.

On the other hand, I think that functional patterns

(see http://www.informatik.uni-kiel.de/~mh/papers/LOPSTR05.html )

are a quite useful language extension. If one adds this

to Curry (as done in PAKCS), it makes sense to allow

different kinds of patterns in function declarations

and case/let expressions. Therefore, I have no problem

to make this distinction.

I think this is interesting and I am in favor of it.

This has also the advantage that intermediate languages

like FlatCurry (which is based on an fcase/case distinction)

do not introduce syntactic constructs that are not present

in the source language.

Best regards,

Michael

_______________________________________________

curry mailing list

curry_at_lists.RWTH-Aachen.DE

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

Received on Do Jan 06 2011 - 09:49:01 CET

*
This archive was generated by hypermail 2.3.0
: Mi Jan 22 2020 - 07:15:08 CET
*