Re: Proposal: Change semantics of pattern matching

From: Wolfgang Lux <>
Date: Tue, 26 Sep 2000 18:46:00 +0200

In response to my proposal

Michael Hanus <> wrote:
> I agree that this could be annoying (in particular, since we
> have a module for Okasaki's red-black trees), but on the other
> hand, the proposed change has important consequences on the
> declarative flavor of Curry. In Curry, each equation defining
> a function has a true equational meaning: each subterm
> matching the left-hand side is replacable by the right-hand side.
> In Haskell, which has the proposed matching behavior, one could
> have a program containing
> ....
> f x = 2
> but the evaluation of (f 0) might return just 1 depending on
> rules written above, i.e., rules have no longer a "local"
> meaning by its own. However, I think that compositionality is important,
> i.e., the meaning of a function should be composed by its
> individual rules. If this is not the case, this should
> be clearly marked. I feel that an eval annotation is not
> enough since the other kind of eval annotations only
> influence the operational but not the declarative meaning
> of functions. To overcome this annoying situation,

But we already have eval choice in the language, which *does* change
the declarative meaning of the program.

> I would prefer to annotate the individual rules to make
> it explicit that this rule has not an equational meaning,
> for instance like in Juanjo's proposal for default rules as
> ...
> default f x = 2

I don't know Juanjo's proposal. How does it generalize to functions
with more than argument or nested arguments? For example, how is the
following Haskell function translated into a deterministic Curry
function with default rules?

  data T = A | B | C | D
  foo A _ = 0
  foo _ A = 0
  foo B _ = 1
  foo _ B = 1
  foo _ _ = 2


Wolfgang Lux				  Phone: +49-251-83-38263
Institut fuer Wirtschaftinformatik	    FAX: +49-251-83-38259
Universitaet Muenster		      Email:
Received on Mo Okt 02 2000 - 08:42:37 CEST

This archive was generated by hypermail 2.3.0 : Mi Jul 28 2021 - 07:15:03 CEST