TEMPORAL SEMANTICS OF A CONCURRENCY MONAD WITH CHOICE AND SERVICES Thomas Frauenstein
Technische Universitat Berlin, Fachbereich Informatik
and Wolfgang Grieskamp
Technische Universitat Berlin, Fachbereich Informatik Sekr. FR5-13, Franklinstr. 28/29, 10587 Berlin
E-mail:
[email protected] and Mario Sudholt
Technische Universitat Berlin, Fachbereich Informatik
ABSTRACT We describe the concurrency monad of the functional language Opal, which realizes a smooth integration of concurrent processes in a purely functional framework, providing a general choice and client-server based communication. We develop an axiomatic semantics for the concurrency monad using a variant of temporal interval logic as syntactic sugar on top of the logic of computable functions.
1. Introduction Extensions of the well-known I/O monad by concurrency and communication have recently been designed and implemented in the context of pure functional languages such as Haskell or Opal [12, 5]. These extensions, which have been applied, for instance, to the construction of graphical user interfaces [4, 5], raise the question of an adequate semantic model of I/O monads in the presence of indeterministic computations. We present a semantic model for the concurrency monad of the purely functional programming and speci cation language Opal [3] which is formulated by means of a temporal axiomatization. This axiomatization bases on the logic of computable functions, LCF [18], on top of which we put a temporal calculus that is an instance of interval logic [17, 2]. The intention is not only to get a semantics for the concurrency monad but also to make a rst step towards a framework that is suitable for formal reasoning about concurrent monadic programs in a standard logic such as LCF. Our axiomatization is based on the idea of linear state-transition systems, the generic model for temporal logics [15], which is closely related with the state-transformer semantics usually associated with monads. The execution of a linear state1
transition system is understood as a sequence of transformation steps on a global state. The semantics of a system description is a class (set) of state-transition traces each of which describes one possible (indeterministic) behavior of the system. Concurrency is treated on base of the so-called \synchronicity hypothesis": from one step to the next concurrent activities synchronously induce e ects on the global state. In order to apply this model to the world of monads, we interpret monadic values as a loose class of functions, each of which computes an interval of global statetransition steps. The members of such a class represent the implemented or speci ed behavior of the monadic value in combination with all possible e ects from the environment. Parallel composition can be naturally explained as the intersection of the classes of interpretations of two monadic values, yielding those interpretations that are \compatible" with each other. Since a monadic program is de ned by one (composed) monadic value, and because we have one \world", that is, global state, we are able to lift indeterminism entirely to the level of model classes, thereby preserving the pure functional framework. Pureness is preserved in the following sense: whereas in the usual monadic framework a program with side-e ects is described as a single pure function on a global state, in our framework a concurrent program with indeterminism is treated as a set of pure functions on a global state. The rest of this paper is organized as follows. In Section 2 we introduce the basic syntax and pragmatics of the concurrency monad of Opal and outline its application. In Section 3, after brie y discussing our logical framework, the temporal semantics of the concurrency monad is presented. Section 4 reviews related work and Section 5 draws the conclusions.
2. The Concurrency Monad We assume that the reader is familiar with functional programming and monadic I/O (see e.g. [13, 9]). In this section we present the concurrency monad of Opal, which provides a general choice, value-result agents, and client-server based communication. 2.1. Language
We abstract from the high-level language features of Opal, such as structures, parameterization and so on, and use a functional kernel language, called Opal, which is a simply-typed polymorphic -calculus with free-type declarations. We denote free types as in type void == nil type bool == true false which introduces the 0-arity type-constructors void and bool and the 0-arity value constructor nil, true and false. j
2
A special feature of Opal is the use of type variables in constructor functions which are not bound in the constructed type. For example, we can de ne a free type type dyn == dynamic with the constructor dynamic of type dyn. This ability is based on the concept of dynamic types, which does not add essentially new semantic features to a simple-typed -calculus [6, 1]. !
2.2. Basic Monadic Structure
In Opal the values of the I/O monad are traditionally called commands, and we stick to this naming convention here. The basic signature of the concurrency monad is given below (read com as \command"):
type com fun yield : fun ; :
! com com ! ( ! com ) ! com
We assume that the reader is familiar with monadic programming and only note that yield v (result in Haskell) constructs a command yielding v , and that c ; f denotes a command which rst executes c and then executes f v , where v is the value yielded by the execution of c . 2.3. Monadic Choice
If we think of a concurrent system as a collection of independent sequential activities that synchronize themselves in some way, we need a programming feature that allows a sequential activity to indeterministically choose between several synchronization possibilities. As a matter of fact, the choice can be treated independently of the actual underlying communication paradigm, and we therefore look at its de nition rst. The monadic choice operator is a binary composition function on commands of the same type: : com com com fun Informally, its semantics is given as follows. In c c only the command that is enabled rst will be executed. If both commands are enabled at the same time, then one of them will be chosen indeterministically. The result of the choice is the result of the chosen command. Enabling is de ned on the base of certain conditions related to atomic commands which will be introduced below. The atomic command yield v is always enabled .
!
!
1
2
a
Note that in contrast to the concept of \external choice" in process algebra (e.g. CSP [10]), the monadic choice is decided by the enabling condition of any atomic command, even if it has no external (communication) e ects such as yield v . a
3
The notion of enabling condition carries over to composed commands. This is best described by considering the canonical form (c ; f ) : : : (cn ; fn ) which can be constructed for each composed command, where the ci are atomic commands. The overall construct is enabled if anyone of the \heads" ci in some path of the choice is enabled. 1
1
2.4. Agents
An agent sequentially executes a monadic command concurrently with other agents and (possibly) terminates with the result of this command. The basic signature is given below:
type agent fun spawn : fun await :
(
com ! com agent agent ! com
)
Agents are of the polymorphic type agent , where is the type of the result of an agent's execution. The function spawn c creates an agent that concurrently executes the command c ; spawn immediately returns the agent identi er. Agents can wait for the termination of other agents and obtain their return value using the function await a , where a is an agent identi er. This command is enabled if and only if the agent a has been terminated. 2.5. Services
The major communication method supported by the concurrency monad is guarded client-server communication | a higher level abstraction than, for example, channels that are frequently employed . Services are managed via so-called service access points (henceforth sap). Once a sap has been created, agents that know about it can request or provide services on it. A service access point is a rst-order citizen, which can be passed to functions and stored in data values. b
type sap fun newSap : fun @ : fun ( ; ) : )
(
)
com sap sap ! ! com sap ! ! bool
(
)
!
(
!
com
) ! com
The type sap is parameterized with the types of the input and output data of a client-server communication. saps are created using the function newSap. Services are provided on a sap s with the command s (g ; c ), which o ers a service described by c that is guarded by the predicate g . Services are requested by the command s @ v . A pair of request and o er commands that are simultaneously executed by b Note, however, that services are also used, for example, in the imperative language Ada [14]. )
4
di erent agents on the same sap are both enabled if the guard g v is true for the input value v of the request. Both agents are then said to enter a rendezvous. During the rendezvous, the requesting agent waits until the o ering agent has nished the execution of the command c v ; the result of this execution is yielded both by the request and by the o er command. 2.6. Example
As an example for the usage of the concurrency monad introduced above we realize a state variable which provides, among getting and setting the state, the possibility of tracing conditions: type act == set (value : ) get trace (cond : bool) type var == sap fun newVar : com (var ) The implementation spawns for each variable an agent that encapsulates the current state: def newVar x == newSap ; ( s spawn (beh s x ) ; ( yield s )) fun beh : var com void def beh s x == s ( a get? a ; yield x ) ; ( beh s x ) s ( a set? a ; a yield (value a )) ; ( x beh s x ) s ( a trace? a cond a x ; yield x ) ; ( beh s x ) We can now use commands such as v @ set 23 or v @ get to set or get the value of a state variable v , or v @ trace ( x x 42) to trace a condition on the state. The last command will be enabled i the given predicate function evaluates to true on the current state of the variable. Note that an alternative realization of state variables may use a triple of saps, each of which realizes one of the services get, set and trace. The choice above would then range over service o ers on di erent saps. j
j
!
!
!
)
)
)
!
0
^
0
3. Temporal Semantics In this section we present a temporal axiomatization of the concurrency monad given in Section 2, following the basic approach outlined in the introduction. We rst sketch the logical framework. We then introduce the abstract type of states and a temporal logic to express observations on states. We nally apply this model to the axiomatization of the concurrency monad. 3.1. Logical Framework
We presume that our object language Opal is embedded in an LCF-style [18] 5
rst-order predicate calculus. In the model of LCF, monomorphic types are interpreted by complete partial orderings and polymorphic types by families of such orderings, indexed by the monomorphic instantiations. Atomic predicates are based on the partial ordering of domains: the formula e e (with e and e having the same type) holds i for all assignments of the type variables and assignments of the free value variables, the ordering relation holds in the associated domain. Equivalence, e e , is de ned as an alias for e e e e . For each type , we have a special expression which denotes the least element in the associated domain of . As logical connectivities we have negation, conjunction, disjunction and existential and universal quanti cation as usual. For the basic axioms and rules of LCF, the reader is referred to [18]. Throughout this paper, non-closed formulae are interpreted as closed ones in that all free variables are considered to be implicitly bound by an outermost universal quanti er. 1 v
1
1 v
2
2 ^
2
2 v
1
2
1
?
3.2. The State
Our axiomatization is based on observations of an abstract global state, which is given by the Opal type state. Values S of type state represent the complete history of the execution of a system up to a certain point in time. The domain ordering S S stands for historical re nement. The initial state is de ned as the least state such that @ . For each state S A , we demand that predecessors are uniquely determined: the cpo of states is a tree, whose root is , with state representing the unde ned tree. In the sequel, all quanti cations over the type of states are implicitly restricted to de ned states S . We use some abbreviations to allow a convenient formalization of properties related to states. The (unique) direct predecessor of a state S is denoted as prec S . Let S and S be states, then S S i S is a least upper bound of a chain containing S . We call a state nite, denoted as fin S , if the chain leading to it, S S : : : S , is nite. The usual interval notation is used on states: the formula S [S : : : S ] abbreviates the formula S S S . A left-open interval is written as S (S : : : S ], which is an abbreviation for S @ S S . Interval notation may be also used in quanti ers as in S (S : : : S ] , which abbreviates S S @ S S = . On states we have a linear order which represents a notion of time: S S holds i S is reached by less or the same number of steps then S , formally: v
0
?
?
w
0
t
0
0
v
1 v
2 v
2
1 v
v
1
8
2
1
1
2
2
2
v
1
8
1
v
2
)
0
()
S vS
0
_
prec S
2
2
2
0
S S
v
prec S
0
3.3. Representing Commands
A command is represented by the Opal type 6
0
type com == wrap (state
!
agent
! state)
The identi er of the agent which executes the command is passed as a parameter in addition to the parameters as known from the usual state-transformers which implement monads. We have embedded the state transformer in a free type because we do not want to consider all functions belonging to the given function space as valid commands. Notationally, we take the liberty of using objects of type com directly as functions, regarding wrap as being an invisible constructor. 3.4. Temporal Observations
States are inspected by expressions of type state , called observers. For the convenient notation of observations, a variant of interval-based temporal logic is de ned as syntactic sugar on top of our logical calculus. A temporal formula is embedded in the logical calculus by the formula SS , where (S : : : S ] is the interval of states in which it holds. Let [ ] be a state formula (see below), c a command and a an agent identi er. The syntax of temporal formulae is de ned as follows: !
hj
0
ji
0
;
::= d []e j d []e j 1 a 2 j : j 1 ^ 2 j c ::= 0 < ` j ` < 1 j 0 < ` < 1 j ` = 1
a
v j 1 \ 2 j 1 [ ] 2
In a state formula [ ], for all applications of observers of type state , the state parameter is \invisible". We use the notation [S ] to substitute all \invisible" state occurrences by the state S , yielding a standard formula. The meaning of temporal formulae (without the choice, ) is then given as follows, with explanations below: [ ] SS ( S (S : : : S ] [S ]) S ( S (S : : : S ] [S ]) S @ S [ ]
