Report on Curry |
Since the design and implementation of Curry is under development, the language definition contained in the report should be considered as preliminary in various aspects. Nevertheless, the report is the main reference on Curry so that implementations of Curry should refer to this report to explain restrictions or differences.
If you are interested in a general introduction to programming in Curry, please look at the tutorial on Curry.
Here you can also find a Java applet for showing syntax diagrams for Curry which can be easily traversed by clicking on the corresponding grammar symbols.
Changes to the previous version:
let x free in x".
See the discussion in the Curry mailing list.
l | b1 = r1
| b2 = r2
...
| bn = rn
where each bi has type "Bool", is considered as an abbreviation for
l = if b1 then r1 else
if b2 then r2 else
...
if bn then rn else undefined
(where "undefined" is a non-reducible function).
This means that Booleans guards have a sequential reading
rather than a parallel one which is reasonable for constraints.
For convenience, the function "otherwise" (=True) is predefined.
l | g1 = r1
| ...
| gn = rn
by typing each gi separately without any further assumptions,
yielding type ti for gi. After that, all ti must be
unifiable to either "Constraint" (default case) or "Bool".
Thus, a mixture between Constraint and Bool guards is not
allowed (see Section 2.2.2).
merge eval choice
merge [] l2 = l2
merge l1 [] = l1
merge (e:r) l2 = e : merge r l2
merge l1 (e:r) = e : merge l1 r
This definition is simpler and really lazy in contrast to the
old use of the "choice" construct. The following operational
behavior for a function call with evaluation annotation "choice"
is informally defined as follows: