Update on Curry report

From: Michael Hanus <hanus_at_I2.Informatik.RWTH-Aachen.DE>
Date: Fri, 6 Jun 1997 18:32:41 +0200

Dear Colleague,

I have updated the report on Curry.
This update is based on the discussion which we had on this mailing
list and further discussions with individual people.
The new version is available via the Curry web pages or directly at


In order to encourage the discussion on the proposed changes,
I summarize the most important changes w.r.t. the first version of
December 5, 1996:

- the syntax is made compatible with Haskell

- restriction to confluent programs are dropped, i.e., non-deterministic
  functions are allowed, but sufficient criteria to ensure
  "well-definedness" of functions in the traditional sense are given,
  see Section 2.2

- equational constraints and concurrent conjunction introduced (Section 2.3)

- meaning of committed choice modified (now it is compatible
  with concurrent constraint languages)

- Prelude added (Appendix B)

- Syntax added (Appendix C)

The main conceptual change is the introduction of equational
constraints, which are described in Section 2.3.
This is only a slight conceptual modification (on the level of
types), but it solves a lot of problems with the current definition
of equality. Here are the main ideas concerning the introduction of
equational constraints:

1. Distinguish between usual Boolean functions (as in Haskell)
   and constraints. Boolean functions can deliver True and False
   as result values, whereas constraints are either satisfiable
   and the computation proceeds or unsatisfiable and the computation
   is discarded. Since the type of Boolean values is different
   from constraints, you cannot apply the function "not" to negate
   constraints (this causes one of the problems in the old version).
   If one wants to compute with negative constraints, the constraint
   system (currently only equations on data terms) must be enriched.
   Thus, we distinguish between the test equality t1==t2, which a Boolean
   function like in Haskell (since it suspends if one argument is an unkown
   value), and the equational constraint {t1=t2}, which must be
   solved in order to proceed the computation and thus may bind
   unknown arguments. In terms of Saraswat's framework for concurrent
   constraint programming, t1==t2 corresponds to "ask" and {t1=t2} to

2. Constraints are applied (i.e., solved) only in conditions of
   function rules, i.e., the condition of a function
   rule has not type Bool but type "constraint" (in contrast
   to the condition in if-then-else which has type Bool since
   the outcomes True and False are necessary). This view
   is fully compatible with logic programming and CLP
   where the constraint in the conditional part must be satisfied
   in order to apply the rule. If the constraint is not satisfiable,
   then this rule cannot be applied. In order to be compatible
   with Haskell, a Haskell rule "l | b = r" can be viewed
   as equivalent to "l | {b=True} = r". This clearly shows
   that one is interested in only computing the value True for
   the condition.

3. Constraints can be constructed using the (concurrent) conjunction
   /\, i.e., the sequential conjunction && of Haskell is a Boolean
   function whereas /\ works on constraints. An important difference
   is that a constraint {c1 /\ c2} can be evaluated concurrently.
   Thus, all potential parallelism is expressed by constraints,
   while the functional kernel (without constraints) expresses
   a sequential computation. This point of view is compatible
   with recent parallel functional languages like Goffin or Eden:
   They use Haskell as a kernel language plus a coordination
   language (constraints in Goffin, process constructs in Eden)
   to express parallelism. By this simple distinction between
   Boolean functions and constraints, Curry does not only
   cover CLP but also covers and generalizes concurrent constraint
   languages and functional parallel languages.

4. Since constraints are first-class citizens, one can also
   define functions to generate constraints (which corresponds
   to "skeletons" of high-level parallel languages). Functions
   could also have constraints as parameters, but the only way
   to use a constraint parameter is to pass it to the output or
   apply it in the condition of its rule.

5. The introduction of constraints makes it also clear how to
   connect external constraints solvers or enrich Curry with
   more sophisticated constraint structures (like disequality,
   arithmetic, or finite domain constraints): constraints are
   only applied or tested for satisfiability in conditions of rules.

6. The introduction of constraints solves also some problems
   which we have in connection with encapsulated search, but this
   will be the topic of a future version.

You may look into the report for examples, in particular
Appendix A.5, where I have added a simple example how to do
concurrent object-oriented programming in Curry.

I hope that you agree with this proposal, since, after working
with this, I become more and more convinced that this is a
reasonable way to go.

If you want to see some really running examples, you could also
use our prototype implementation of Curry. This implementation,
called TasteCurry, is implemented by a very simple interpreter
written in Prolog. It is slow, but it implements a substantial
subset of Curry (e.g., it has polymorphic type inference,
an automatic generator for definitional trees, higher-order
functions and lambda-abstraction, local "where"-declarations,
monadic I/O, comitted choice etc). Since we haven't written any
parser, we use a Prolog-like syntax instead of concrete Curry
syntax, but I hope this will be improved in the next time
with the help of Sergio Antoy. You can run this interpreter
via our web interface for running TasteCurry programs. Please look at



Any kinds of comments are welcome!

Best regards,

Received on Fr Jun 06 1997 - 19:36:00 CEST

This archive was generated by hypermail 2.3.0 : Do Dez 07 2023 - 07:15:07 CET