From a Concurrent Logical Framework to

Concurrent Logic Programming

Jeff Polakow
April 11, 2006
LolliMon [9] is a new monadic concurrent linear logic programming language
which grew out of the analysis of the operational semantics of term construction
for the concurrent logical framework (CLF) [16, 15, 4]. Alternatively, LolliMon
can be seen as an extension of the linear logic programming language Lolli [8]
with monadically encapsulated synchronous [1] formulas. The use of a monad
allows LolliMon to cleanly integrate backward chaining and forward chaining
proof search in one language; forward chaining concurrent executions are
cleanly encapsulated, via the monad, inside backward chaining serial executions. This article attempts to elucidate the transition from logical framework
to logic programming language; we will also point out some interesting aspects
of our implementation and directions for future work. A prototype disrtibution
of LolliMon is available online at: www.cs.cmu.edu/~fp/lollimon.
CLF conservatively extends the linear logical framework (LLF) [3], itself a
linear extension of the Edinburgh logical framework (LF) [7], with constructs
allowing for the elegant encoding of concurrent computations. The LF family
of logical frameworks are all based on dependently typed lambda calculus and
rely upon the notion of canonical forms to ensure adequacy of object system1
representations; therefore these logical frameworks only contain types which
admit canonical forms.
The existence of canonical forms for the LF family of logical frameworks additionally allows an operational semantics for term construction finding a term
of a given type which corresponds to higher-order logic programming [13].
The type language of LF corresponds to (the freely generated fragment of) the
formula language of -Prolog [11] and the operational semantics of term construction, respectively proof search, for the two systems coincide. Similarly the
type language of LLF corresponds to the formula fragment of Lolli, a linear
extension of -Prolog, and their operational semantics also coincide.
Although -Prolog and Lolli were developed before LF and LLF, one can
view the two logic programming languages as implementations of the term construction algorithms for the two logical frameworks. The notion of uniform
1 The systems we wish to use the logical framework to reason about; this use of object
system is in contrast to meta system (the logical framework) and has nothing to do with
object-oriented design.

proof [12], which is central to Prolog style logic programming and corresponds
to canonical forms via the Curry-Howard isomorphism (and a translation from
natural deduction to sequent calculus), provides the necessary mechanism for
finding canonical terms of a given type. Similarly techniques for linear resource
management [2, 14, 10], which constrain the non-determinism of linear context
splitting inherent in backward chaining linear logic proof search, provide the
necessary machinery for tractable linear lambda term construction.
A significant property of the type systems for LF and LLF is that the shape
of a term, of non-atomic type, is independent of the current variable context;
types with this property are called asynchronous [1]. Thus a term of type
will have the form x : .m, and a term of type & will have the form hm, ni;
this allows proof search in -Prolog and Lolli to be goal directed. However the
type language of CLF, which includes synchronous types such as , does not
have this property. A sequent derivation of = > must first decompose
the hypothesis before the goal:
>
= init
= > R
R
, = >
L
= >
In general, the derivation of any synchronous formula can require decomposing hypotheses before the synchronous goal. To allow synchronous types and
still have a notion of canonical forms, CLF introduces a monadic type constructor, {}, which will be used to mark all occurrences of synchronous types; thus
CLF disallows terms of type , but does allow terms of type { }. By restricting synchronous types to only occur within the monadic type constructor,
CLF regains a notion of canonical forms where a term of type {} has the shape
{let {p1 } = e1 in . . . let {pn } = en in e} where pi is a variable pattern whose
shape is determined by the type of ei , a term representing the decomposition of
some monadic hypothesis; e is a term of type ; and we have overloaded {} to
also be a term constructor.
In other words canonical terms of monadic synchronous type are a (possibly
empty) sequence of operations on hypotheses followed by a term of appropriate type; this exactly captures the need to decompose hypotheses before the
goal when deriving a synchronous formula. The preceding notion of canonical
form for CLF places no constraints on the sequence of hypothesis operations
executed before returning to the goal. In this way synchronous types resemble
atomic types; there is not necessarily a single term for a given atomic type.
However, restricting the occurrence of synchronous types to being inside the
monad, effectively encapsulates the uncertainty in an otherwise canonical term.
Operationally, the derivation of a monadic goal entails a switch from backward chaining, goal directed proof search to forward chaining, context directed2
proof search; after enough forward chaining has taken place, search can resume
its goal directed nature. Determining when to stop forward chaining is a matter of proof search strategy; there is in general no way of deciding when to
2 The

derivation is driven by the current hypotheses, rather than by the current goal.

stop, short of a global analysis which would be tantamount to finding a complete derivation. One strategy, which we have adopted in the implementation
of LolliMon, is to forward chain until the context reaches a fixpoint.
The monadic formula constructor was intended to encapsulate synchronous
formulas, however its operational significance, i.e. switching from backward
chaining to forward chaining, makes it useful even in the absence of synchronous
formulas. In particular, the monad can be used, in conjunction with embedded implications, to syntactically separate distinct phases of a forward chaining
computation [9].
Although there are no constraints placed on the sequence of forward chaining
operations in a monadic term, the order of any two independent operations
may be switched without affecting the meaning of the term. Intuitively, the
operations on hypotheses all happen concurrently with an ordering of events
only forced by data dependencies and resource contention (when two hypotheses
require the same linear hypothesis). Therefore the definition of equality for CLF
allows for directly encoding true concurrency; the system cannot differentiate
between two terms which only differ in the order of independent operations.
Many concrete examples of CLF encodings are provided in the technical report
by Cervesato et al. [4].
The faithful operational translation of CLFs concurrent equality would be
to treat (monadic headed) hypotheses as concurrent processes, similar to rewriting rules [6] or linear concurrent constraints [5], which are turned on during a
forward chaining stage. The current prototype version of LolliMon does not attempt concurrent execution and instead randomizes the order in which it tries to
use each monadic hypothesis. Additionally, true concurrency is approximated
by making the forward chaining phase of proof search committed choice. While
this approach does prevent the system from finding two equivalent proofs, it is
too restrictive and leads to incompleteness. We plan to explore truly concurrent
execution in the future.
The implementation of LolliMon requires the interleaving of backtracking,
goal directed proof search with committed choice, forward chaining proof search.
As already stated, a goal formula can have a monadic goal nested inside and
cause backchaining search to switch to forward chaining search. Likewise, a
backchaining derivation can be spawned in the middle of forward chaining when
decomposing an implication hypothesis. The arbitrary nesting of the two different search strategies poses interesting implementation challenges. The current
version of LolliMon uses both success and failure continuations to manage control flow. In order to interleave backtracking proof search with committed choice
search, the failure continuation values are structured to reflect the nesting of
backtracking and non-backtracking phases. Although this approach seems to
work reasonably well, it feels too ad hoc and we believe LolliMons operational
semantics and control flow can be much more cleanly specified.
In order to check whether or not the context has reached a fixpoint, or has
saturated, we need to know whether a given formula is already in the context. To
keep the saturation check tractable, the current implementation uses a version
of a discrimination tree to store the entire context; thus we can also make use of
3

indexing to more efficiently solve atomic goals. In order to match the depth first
Prolog style search semantics, we sacrifice some amount of sharing to maintain
clause order information when storing backchaining program clauses; however
monadic clauses, and clauses assumed during forward chaining, are always stored
with maximal sharing.
Although we can efficiently decide whether or not a given formula is already
our context, we do not yet have a good way of reaching context saturation,
during forward chaining. Currently, our method of reaching saturation is to try
every available formula until none produce a change; however, if any formula
produces a change in the context during a pass, then we schedule another pass
in which every formula wiull be tried again. This is highly inefficient since many
formulas will independent of each other. We are currently working on adding
information to our discrimination tree structure which will let us turn off a
branch of the tree until some specific event happens which triggers the formulas
in that branch to come back alive. We hope to be able to leverage standard
techniques from data flow analysis for logic programs and spreadsheets.
Finally, we end by noting that the current committed choice forward chaining
strategy of continuing until saturation, or a fixed point, is reached is not the
only, nor even the best strategy. We chose this strategy because it is relatively
simple for both the implementor and the user, and it approximates the CLF
semantics. However, the strategy is incomplete due to the side effects caused by
linear hypotheses as well as unification. We would like to explore other forward
chaining strategies. In particular a (non-deterministically) complete strategy
would allow us to use LolliMon for model checking since a negative result would
really mean no proof exists.

References
[1] J.-M. Andreoli. Logic programming with focusing proofs in linear logic.
Journal of Logic and Computation, 2(3):297347, 1992.
[2] I. Cervesato, J. S. Hodas, and F. Pfenning. Efficient resource management
for linear logic proof search. Theoretical Computer Science, 232:133163,
2000. Revised version of paper in the Proceedings of the 5th International
Workshop on Extensions of Logic Programming, Leipzig, Germany, March
1996.
[3] I. Cervesato and F. Pfenning. A linear logical framework. Information and
Computation, 1999. To appear in the special issue with invited papers from
LICS96, E. Clarke, editor.
[4] I. Cervesato, F. Pfenning, D. Walker, and K. Watkins. A concurrent logical
framework II: Examples and applications. Technical Report CMU-CS-02102, Department of Computer Science, Carnegie Mellon University, 2002.
Revised May 2003.

[5] F. Fages, P. Ruet, and S. Soliman. Linear concurrent constraint programming: Operational and phase semantics. Information and Computation,
165(1):1441, 2001.
[6] T. Fr
uhwirth. Theory and practice of constraint handling rules. Journal of
Logic Programming, 37(13):95138, Oct. 1998. Special Issue on Constraint
Logic Programming.
[7] R. Harper, F. Honsell, and G. Plotkin. A framework for defining logics.
Journal of the Association for Computing Machinery, 40(1):143184, Jan.
1993.
[8] J. S. Hodas and D. Miller. Logic programming in a fragment of intuitionistic linear logic. Information and Computation, 110(2):327365, 1994. Extended abstract in the Proceedings of the Sixth Annual Symposium on
Logic in Computer Science, Amsterdam, July 1518, 1991.
[9] P. L
opez, F. Pfenning, J. Polakow, and K. Watkins. Monadic concurrent
linear logic programming. In PPDP 05: Proceedings of the 7th ACM SIGPLAN international conference on Principles and practice of declarative
programming, pages 3546, New York, NY, USA, 2005. ACM Press.
[10] P. L
opez and J. Polakow. Implementing efficient resource management
for linear logic programming. In F. Baader and A. Voronkov, editors,
Eleventh International Conference on Logic for Programming Artificial Intelligence and Reasoning (LPAR04), pages 528543, Montevideo, Uruguay,
Mar. 2005. Springer-Verlag LNAI 3452.
[11] D. Miller and G. Nadathur. Higher-order logic programming. In E. Shapiro,
editor, Proceedings of the Third International Logic Programming Conference, pages 448462, London, June 1986.
[12] D. Miller, G. Nadathur, F. Pfenning, and A. Scedrov. Uniform proofs as
a foundation for logic programming. Annals of Pure and Applied Logic,
51:125157, 1991.
[13] F. Pfenning. Logic programming in the LF logical framework. In G. Huet
and G. Plotkin, editors, Logical Frameworks, pages 149181. Cambridge
University Press, 1991.
[14] J. Polakow. Linearity constraints as bounded intervals in linear logic programming. Journal of Logic and Computation, 2006. To appear. Extended
version of paper in Proceedings Workshop on Logics for Resources, Processes, and Programs, Turku, Finland, July 2004.
[15] K. Watkins, I. Cervesato, F. Pfenning, and D. Walker. A concurrent logical
framework I: Judgments and properties. Technical Report CMU-CS-02101, Department of Computer Science, Carnegie Mellon University, 2002.
Revised May 2003.

[16] K. Watkins, I. Cervesato, F. Pfenning, and D. Walker. A concurrent logical framework: The propositional fragment. In S. Berardi, M. Coppo,
and F. Damiani, editors, Types for Proofs and Programs, pages 355377.
Springer-Verlag LNCS 3085, 2004. Revised selected papers from the Third
International Workshop on Types for Proofs and Programs, Torino, Italy,
April 2003.