Minutes of a meeting on Curry

From: Michael Hanus <hanus_at_informatik.rwth-aachen.de>
Date: Wed, 6 May 1998 18:41:20 +0200

Dear Colleague,

I want to inform you by this email about the results
of a recent meeting where we discussed some topics
related to Curry.

The meeting took place during the 7th International Workshop
on Functional and Logic Programming in Bad Honnef in the
evening of April 27, 1998. The following persons attended the
meeting: Rachid Echahed, Michael Hanus, Herbert Kuchen,
Wolfgang Lux, Julio Marino, Juanjo Moreno Navarro, Frank Steiner,
and Frank Zartmann.

The main topic was the discussion of the current proposal for the
Curry language (as defined in the report of February 1998).
After discussing the changes in this version, there was
an agreement about the current general conceptual design of the
language. We agreed also on some minor changes which will
be added in some future version of the report (these are
listed below).

Another important topic was the implementation of Curry.
Currently, there are the following implementations (ready
as a prototype or under development):

1. The TasteCurry system of RWTH Aachen and Portland State University:
   - Front end with a parser written in Java and everything
     else (type inferencer, module checker, pattern matching
     compiler) implemented in Prolog
   - back end: a (slow) interpreter written in Prolog

2. Curry->Java compiler of RWTH Aachen:
   uses the front end of TasteCurry and compiles into Java (Pizza),
   i.e., uses the JVM as a back end

3. Sloth system of UPM Madrid:
   front end and back end implemented in Prolog, compiles
   Curry programs into Prolog

4. Compiler of Univ. Muenster:
   only a back end, abstract machine for Curry,
   under implementation in C

To coordinate these different developments (two different front ends
and three different back ends!), it seems to be necessary to
define an intermediate language as an interface between
the front and back ends so that implementors interested in
abstract machines can use existing front ends. I'll try
to propose such a language in the near future (maybe based
on an existing proposal by Sergio Antoy).

Possible changes in the language definition:

1. Evaluation annotations:
>From our practical experience, it seems that complicated
evaluation annotations will not be specified by the programmer
since the automatic generation of them is sufficient.
The only important property is whether a function is rigid
or flexible. Thus, the declarations "f eval rigid" and
"f eval flex" seem to be sufficient. The power of the more refined
annotations can be also obtained by the addition of auxiliary
functions. Thus, the more complicated forms of evaluation
annotations might be completely deleted in the future.
Therefore, current implementations can already omit them.

2. Defaults for flex/rigid:
The current default is that functions with result type "Bool"
are flexible and all others are rigid. This is motivated
by translating logic programs into Boolean functions.
On the other hand, logic programs often define predicates
only partially (only the "True" cases are defined)
which is a good argument to translate predicates
from logic programs into constraint functions (i.e., functions
with result type "Constraint"). Thus, it seems preferably
to consider only constraint functions as flexible and
all others as rigid. Therefore, the default might
be changed in the future but currently we keep it
as it is and wait for more practical experiences.

3. Search strategy:
The current report does not fix any search strategy
but proposes the use of encapsulated search. Thus,
some Curry implementation only supports the encapsulated
search operator ("try") but does not implement a predefined
strategy like depth-first search, whereas other implementations
are based (for efficiency reasons) on backtracking and support
encapsulated search as an additional method (which is not so
efficient as built-in backtracking). To avoid forcing
implementors to support built-in as well as encapsulated
search, the language definition will be based only on
encapsulated search. As a consequence, the search strategy
in the top-level of the interactive programming environment
(Section 10 of the report) will be specified in terms of
encapsulated search, e.g., each top-level expression
(except for expressions of type IO ()) is considered
as encapsulated by some search operator (e.g., "all").


Opinions or additions to these topics are welcome.

Best regards,

Michael
Received on Mi Mai 06 1998 - 19:45:00 CEST