Curry: An Integrated Functional Logic Language

Eval [e; rule(l | c = r)] ⇒ {id σ(c|r)}
if σ is a substitution with σ(l) = e
Eval [c] ⇒ D
Eval [c|e] ⇒ replace(c|e, 1, D) Eval [success|e] ⇒ {id e}
Figure 3: Evaluation of conditional rules
always shared, i.e., if an argument of a function is instantiated during a call to this function to
an expression and this expression is evaluated to some value (head normal form), then all other
expressions resulting from instantiating occurrences of the same argument are replaced by the
same value (head normal form). 21 This is necessary not only for efficiency reasons but also for the
soundness of the operational semantics in the presence of non-deterministic functions, as discussed
in Section 2.3.1. The sharing of variables can be described with the more complicated framework
of graph rewriting. Formal descriptions of graph rewriting and narrowing can be found in [15, 18].
D.3 Committed Choice
To define the semantics of calls to functions with the evaluation annotation choice, we assume
that all such calls are enclosed by choice(. . .). Now we extend the rules in Figures 2 and 3 for
covering such choices. An expression choice(f(e1, . . . , en)) is reduced as follows. If
Eval [f(e1, . . . , en)] ⇒ ∗ {. . . , σ success|ϕ(r), . . .}
according to the operational semantics described in Figures 2 and 3, where l | c = r is a rule for
f, 22 σ does not bind any free variable occurring in f(e1, . . . , en), and this is the first step in the
derivation with this property, then Eval [choice(f(e1, . . . , en))] ⇒ {id ϕ(r)}.
Thus, if disjunctions occur due to the evaluation of a call to a choice function, these disjunctions
are not distributed to the top-level but are kept inside the choice expression. If one rule for
the choice function becomes applicable (without binding of free variables in this call), all other
alternatives in the disjunction are discarded. Hence, a call to a choice function corresponds to the
committed choice (with deep guards) of concurrent logic languages. This can be implemented by
evaluating this call (with a fair strategy for alternatives) as usual but with the restriction that only
local variables can be bound.
D.4 Equational Constraints
An equational constraint e1=:=e2 is solvable if both sides are reducible to a unifiable data term
(strict equality). An equational constraint can be solved in an incremental way by an interleaved
21 It should be noted that values are constructor terms like 23, True, or [2,4,5]. This means that the evaluation
of constraints and I/O actions are not shared since they are not replaced by a value after evaluation but
constraints are solved in order to apply a conditional rule (in case of constraints) and I/O actions are applied
to the outside world when they appear at the top-level in a program. This is the intended behavior since the
expressions “putChar ’a’ >> putChar ’a’” and “let ca = putChar ’a’ in ca >> ca” should have an identical
behvarior, namely printing the character ’a’ twice.
22 An unconditional rule l = r is considered here as an abbreviation for l | success = r.
68