On Wed, Jan 5, 2011 at 6:51 PM, Michael Hanus <mh_at_informatik.uni-kiel.de>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 "_"
>
I like this extension.
> 2. Non-linear patterns in function declarations: allow multiple occurences
> of a same variable in left-hand sides of function declarations.
>
This is reasonable because it is already possible to define non-linear
patterns using function patterns, at least indirectly.
I think using non-rigid equality (=:=) and sequential evaluation (&>) is
most reasonable because pattern matching usually does not residuate (in
function declarations) and is checked before evaluating a guard.
I am in favor of warning programmers about non-linear patterns. Maybe there
is a notion of "non-trivially non-linear patterns" similar to "non-trivially
overlapping rules"? But even without such a notion a warning is useful, in
my opinion, to prevent programmers from using them accidentally.
On Wed, Jan 5, 2011 at 10:58 PM, Wolfgang Lux <wlux_at_uni-muenster.de> wrote:
>
>
> I also have a third proposal: Flexible case (aka fcase) expressions.
On Thu, Jan 6, 2011 at 5:42 PM, Michael Hanus <mh_at_informatik.uni-kiel.de>
wrote:
>
> 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.
Wolfgangs fcase expressions are different from those used in the
intermediate representation of PAKCS because they allow overlapping
patterns.
I consider the current situation of pattern matching in Curry unfortunate.
Patterns are rigid or flexible and have fall-through or non-deterministic
semantics in presence of overlapping rules. The current situation mixes
these aspects. I prefer pattern matching to always be flexible (with
ensureNotFree the only means to residuate). I'd also like to be able to
specify (both for function declarations and case expressions) whether
non-deterministic or fall-through semantics is the intended meaning for
overlapping rules. I think this would be more consistent than the current
situation and would alleviate the need for extra fcase expressions. It does
require extra annotations on function declarations and case expressions,
however, if one wants to defer from the default behavior (which could
preserve the current behavior, apart from residuation). Function patterns
could then be allowed in all kinds of patterns with non-deterministic
semantics.
Best regards,
Sebastian
P.S. Just yesterday I was slightly annoyed by the absence of fall-through
patterns for Curry functions. I would not know how to write the function
'updStack' (starting at line 571 of the program linked below) without a
fall-through mechanism and would appreciate to be able to choose between
multiple rules or case expressions in such situations.
https://github.com/sebfisch/curry-sqlite3/blob/master/KeyDatabaseSQLite.curry
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Jan 24 2011 - 09:08:55 CET