Objects as Session-Typed Processes
Stephanie Balzer and Frank Pfenning Computer Science Department Carnegie Mellon University, USA
Abstract an extensive survey of the object-oriented literature, Arm- A key idea in object-oriented programming is that objects strong [8] identifies 39 concepts generally associated with encapsulate state and interact with each other by message object-oriented programming, such as object, encapsulation, exchange. This perspective suggests a model of computation inheritance, message passing, information hiding, dynamic that is inherently concurrent (to facilitate simultaneous mes- dispatch, reuse, modularization, etc., out of which she dis- sage exchange) and that accounts for the effect of message tills the “quarks” of object-orientation, which are: object and exchange on an object’s state (to express valid sequences of class, encapsulation and abstraction, method and message state transitions). In this paper we show that such a model passing, dynamic dispatch and inheritance. of computation arises naturally from session-based commu- These findings are consistent with the concepts sup- nication. We introduce an object-oriented programming lan- ported by the protagonists of object-oriented languages: guage that has processes as its only objects and employs lin- Simula [19, 20] introduced the notions of an object and ear session types to express the protocols of message ex- a class and substantiated the idea to encapsulate the op- change and to reason about concurrency and state. Based on erations and the data on which they operate in an object. various examples we show that our language supports the Smalltalk [30] put forward the message-passing aspect of typical patterns of object-oriented programming (e.g., en- object-orientation by viewing computation as message ex- capsulation, dynamic dispatch, and subtyping) while guar- change, whereby messages are dispatched dynamically ac- anteeing session fidelity in a concurrent setting. In addition, cording to the actual receiver object. The Actor model im- we show that our language facilitates new forms of expres- plemented this idea in a distributed and concurrent context sion (e.g., type-directed reuse, internal choice), which are where message-passing is the sole means of exchange be- not available in current object-oriented languages. We have tween actors [6, 34]. implemented our language in a prototype compiler. Viewing computation as the exchange of messages be- tween stateful objects seems to be a key idea in object- Categories and Subject Descriptors D.1 [Programming oriented programming. Alan Kay phrased this view in a Techniques]: Concurrent Programming—Parallel program- publicly available email exchange on the meaning of object- ming; D.1 [Programming Techniques]: Object-oriented oriented programming as follows: “OOP to me means only Programming messaging, local retention and protection and hiding of Keywords object, session types, linear types, process, pro- state-process, and extreme late-binding of all things. It can tocol be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.” 1. Introduction ([42]). This view suggests computation to be inherently con- current, as an object may simultaneously exchange mes- Since its inception in the 1960s [19, 20] and 1970s [30], sages with several objects, and the expression of the proto- object-oriented programming has become a ubiquitous pro- cols that govern message exchange. gramming model. A multitude of object-oriented languages Concurrency support in mainstream object-oriented lan- have emerged since, each with their own characteristics. In guages is the subject of an active area of research. Main- stream object-oriented languages typically support concur- Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed rency by purely operational synchronization idioms (e.g., syn- for profit or commercial advantage and that copies bear this notice and the full citation chronized statements/methods), but leave it to the program- on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, mer to ensure thread-safety of a class and absence of data to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. races. To alleviate the burden put on programmers, type sys- Copyright is held by the owner/author(s). Publication rights licensed to ACM. tem extensions have been suggested that, for example, use AGERE!’15, October 26, 2015, Pittsburgh, PA, USA ownership types [18] to guarantee absence of data races and ACM. 978-1-4503-3901-8/15/10...$15.00 deadlocks [13] or the notion of an interval to make the or- http://dx.doi.org/10.1145/2824815.2824817
13 dering between threads explicit for the prevention of data Session Type Behavior races [44]. Of particular concern are also high-level data !τ; σ Value output: send value v of type τ, continue as races, whose prevention is possible by means of a static process of type σ. analysis [59]. Moreover, a wide range of tools have been de- ?τ; σ Value input: receive value v of type τ, continue as process of type σ. veloped for static [49] and dynamic [25] data race detection. !σ1; σ2 Channel output: send channel of type σ1, continue Considerable effort has been devoted to protocol expres- as process of type σ2. sion in object-oriented languages. Work on typestate [11, 22] ?σ1; σ2 Channel input: receive channel of type σ1, continue allows programmers to annotate methods with the receiver as process of type σ2. !{l1 : σ1,..., ln : σn } Internal choice: send label li , continue as process of object’s typestate in pre- and post-conditions. To check ad- type σi . herence to the protocols expressed in this way, static pro- ?{l1 : σ1,..., ln : σn } External choice: receive label li , continue as process gram analysis techniques are employed [12, 22] that use of type σi . some means to control aliasing, such as fractional permis- Terminate process. sions [14]. Another line of research adopts session types [36, µt. σ Recursive session. 37] for protocol expression in a concurrent context and in- Table 1. Linear session types. corporates session types into existing object-oriented lan- guages [23, 39, 40] based on a linear treatment of channels. In this paper, we take a different approach to supporting Structure: Section 2 provides a short introduction to lin- concurrency and expressing protocols. Rather than extend- ear session types. Section 3 introduces CLOO and the basic ing existing object-oriented languages with concepts nec- correspondence between session-typed communication and essary to address the challenges, we derive a new model object-oriented programming. Section 4 discusses the prop- of object-oriented programming that internalizes the semi- erties of session fidelity, data race freedom, and deadlock nal idea of object-orientation that computation is concurrent freedom. Section 5 elaborates on the new forms of expres- message exchange between stateful objects. Our model takes sion available in CLOO. Section 6 provides a discussion of linear session types as its foundation. This choice is moti- encapsulation and aliasing and an outlook on future work. vated by the observation that object-oriented programming Section 7 summarizes related work, and Section 8 concludes arises naturally from session-typed communication and fa- the paper. cilitates program reasoning, because linear session types guarantee session fidelity and freedom of data races and 2. Background deadlocks. Session types [36, 37] prescribe the interaction behavior We present our concurrent object-oriented language CLOO of processes that communicate along channels, connecting (Concurrent Linear Object-Orientation). In CLOO, pro- an offering process with its client process. A session type cesses are the only objects, and objects interact with each thus governs the protocol of message exchange. Table 1 other by sending messages along channels. Message ex- provides an overview of the kinds of protocols that can be change is asynchronous, and an object is identified with the expressed using session types. For example, the session type channel along which it exchanges messages with its clients. !int;?int; requires sending an integer, then receiving an Objects (and their channels) are typed with session types, integer, and then terminating the session. Besides integers which define the protocol of message exchange. Protocol and other basic data values, processes can also send channels compliance is enforced by CLOO’s type system, relying on along channels (as in the π-calculus [46]) and can offer a linear treatment of channels. external and internal choices. An external choice ?{l1 : An important concern in the development of CLOO was σ1,..., ln : σn } means to receive one of the labels li and to facilitate program reasoning while maintaining a gen- then behave as prescribed by σi . Conversely, an internal uine object-oriented programming style. Based on various choice !{l1 : σ1,..., ln : σn } will send one of the labels li programming examples, we show that CLOO supports the and continue as σi . Session types can be recursive, allowing typical object-oriented concepts, such as encapsulation, dy- for protocol repetition. namic dispatch, and subtyping. In addition, we show that To guarantee that the interaction between a client process CLOO enables new forms of program expression, such as and an offering process indeed follows the protocol defined type-directed code reuse and internal choice, concepts not by the session type, aliasing of channels must be controlled. existing in current object-oriented languages. Whilst type- We treat channels linearly [29], making channels owned by directed reuse supports program extensibility in a similar their client process, with ownership transfer being possible way as inheritance, it does not suffer from the modular- by passing a channel to another process. For example, the ity issues caused by the latter, because type-directed reuse typing rule for a channel output respects encapsulation. We have implemented a prototype compiler for CLOO, which supports most of the features presented in this paper. Σ; ∆, d : σ1 \ ∆ ` send(c, d) :: (c :!σ1; σ2) \ (c : σ2)
14 indicates that the channel d of type σ1 will no longer be typedef ctr; // external choice choice ctr { available to the offering process once it has been sent along
15 OO Remarks CLOO Object A process has state and identity. Its externally observable state amounts to the process’ protocol state, its internal state to Process its local variables. Encapsulation A process’ local variables can only be read or written to by the declaring process, possibly in response to receipt of a message. Encapsulation A process’ protocol state can only be altered by exchanging messages according to the protocol prescribed by the process’ session type. Only a process’ protocol state is externally observable, as it amounts to the process’ session type. Message An external choice’s labels correspond to a class’ methods. In addition, messages can encompass labels of internal choice, Label basic data values, and channels. Message exchange constitutes the sole means of externally observable computation. Reference Communication happens always along a channel, a channel thus being the only means to “access” a process. Channels are Channel bidirectional and owned by the client process. Ownership of a channel can be transferred by passing the channel to another process. Dynamic dispatch The process that will receive a message is determined by the process at the channel endpoint, not generally known at compile Switch time, which then selects the appropriate branch of a switch statement. Subtyping Structural subtyping arises between different forms of external and internal choices. For an external choice, subtyping allows Subtyping a process accepting more choices to be used wherever a subset of those choices is required. For an internal choice, subtyping allows a process offering less choices to be used wherever a superset of those choices is expected.
Table 2. Basic correspondence between object-oriented concepts and CLOO concepts.
// current process offering on channel ’lower’, along $c. For example, upon receiving the label Inc, a // local variable ’b’, uses channel ’higher’ ctr $lower bit(bool b, ctr $higher) { non-empty bit string sets its own bit to true, if it is false, loop { // continue until terminated or asks its next more significant bit process to increment switch ($lower) { // wait to receive label case Inc: itself. Each branch must be ended with an explicit terminat- if (b == false) { ing statement, such as break, close, or forwarding, to b = true; } else { prevent execution from “falling through”. Channel forward- $higher.Inc; // send carry bit as label ’Inc’ ing, such as $lower = bit(true, $zero) in the Inc b = false; eps } branch of process , consumes the current process and break; advises the client process to communicate henceforth along case Val: $higher.Val; the channel to the right of the equal sign. int n = recv($higher); // receive value In addition to process declarations, CLOO supports func- send($lower, 2*n+(b?1:0)); // send value wait($higher); // wait for ’higher’ to terminate tion declarations (not shown in Figure 2). Function decla- close($lower); // terminate rations differ from process declarations in that they return }}} a value of a basic type rather than a session type. There- ctr $lower eps() { fore, the invocation of a function in the body of a process loop { switch ($lower) { does not have an effect on the process’ externally observable case Inc: state. Function declarations are helpful to modularize auxil- // create new ’eps’ process offering on ’zero’ ctr $zero = eps(); iary code. // forward requests to newly created ’bit’ process The example of a counter illustrates that there is a nat- $lower = bit(true, $zero); case Val: ural correspondence between processes and objects. Pro- send($lower, 0); cesses fully encapsulate their state because a process’ lo- close($lower); }}} cal variables are internal to the process and because a pro- cess’ protocol state can only be altered by message exchange Figure 2. CLOO processes implementing session type ctr along the process’ channel. Channels thus correspond to ref- (see Figure 1) as a bit string. erences, being the only way to “access” an object. Chan- nels, however, provide stronger guarantees than their object- oriented counterparts because they implement the protocol a local variable can be triggered by the receipt of a message, prescribed by their linear session type (see discussion in Sec- either along the offering channel or any other channels of tion 4.1). Moreover, channels are bidirectional, which gives which the process is a client. For example, process bit up- rise to the concept of an internal choice, for which there ex- dates its bit upon receiving the label Inc along its offering ists no analog in object-oriented languages (see discussion channel. in Section 5.2). The first four entries in Table 2 summarize A loop statement loop {...} repeats the enclosed these correspondences. code block until the process terminates. Loop statements are typically used to implement recursive session types. Al- ternatively, a recursive session type can be implemented by 3.2 Dynamic Dispatch a recursive process declaration. A switch ($c) {...} To illustrate the fifth correspondence in Table 2, we extend is used to branch on the cases of an external choice for some our example with a different implementation of session type channel $c. It blocks the process until it receives a label ctr. Figure 3 shows this alternative implementation. It com-
16 ctr $c nat(int n) { implementing ctr inc2 can be substituted wherever a pro- loop { ctr switch ($c) { cess of type is expected. case Inc: n = n + 1; break; Our current prototype compiler does not support subtyp- case Val: send($c, n); close($c); }}} ing at this moment, but we expect its implementation to be analogous to [3]. We have already worked out the algorith- Figure 3. CLOO process implementing session type ctr mic type checking rules to accommodate subtyping between (see Figure 1) as an accumulator. non-recursive session types. Next, we will extend our sub- typing relation to a co-inductive subtyping relation between recursive session types, as described in [27]. Our implemen- prises the process declaration nat and keeps the counter in tation will then have to enforce that recursive session types a local variable n. We would spawn such a process with ctr are contractive [27], guaranteeing type checking of recursive $c = nat(0). types to be decidable. Given that there can be multiple implementations of the same session type, CLOO naturally supports a form of dy- 4. Language Properties namic dispatch, where the actual code to be executed in re- In this section, we discuss the safety properties provided sponse to a message is determined by the actual process con- by an object-oriented programming model that is based on nected to the channel at run-time. For example, we could linear session types. have a mixed implementation of a counter where the lower bit 32 bits are processes, each holding one bit, while the 4.1 Session Fidelity upper bits are stored as a single number in a nat process. This form of dynamic dispatch is analogous to the one To make sure that the interaction between processes follows resulting from interfaces and classes in Java-like languages. the intended protocol, CLOO’s type system must guarantee An interface can be implemented by various classes, and the that the session type of a channel along which a client inter- methods defined by the interface are dispatched according acts with a process always coincides with the process’ pro- to the dynamic type of the receiver object. Similarly, the tocol state. For example, once a client has sent the label Val messages a client process sends along a channel in CLOO along a ctr channel, the process bound to the channel can will result in the execution of the code of the process that is only send back an integer value to the client. Any other ex- bound to the channel at run-time. change would be type-incorrect and violate session fidelity. Process declarations relate to classes in Java-like lan- The type checker of our prototype compiler implements cor- guages also from a different point of view. Similarly to a responding checks to ensure session fidelity, a formal proof class, they serve as a “template” from which processes are of session fidelity is in preparation. instantiated. In the next section we substantiate the corre- The key to guaranteeing session fidelity is linearity. Com- spondence between processes and session types and classes munication always takes place along a channel, and a chan- and interfaces, respectively, even further by showing that nel connects exactly two processes, a client process and an processes can implement different session types by subtyp- offering process. While a process can use any number of ing. processes as clients, linearity of channels guarantees that a process offers a service to exactly one other process at any 3.3 Subtyping given point in time. A graph of communicating processes thus amounts to a tree, with ownership transfer being possi- Structural subtyping arises in a linear session-typed lan- ble by passing a channel to another process. guage between different forms of external and internal Linearity also facilitates reasoning about program cor- choices, respectively. For an external choice, we can sub- rectness. For example, due to the absence of aliasing, it is stitute a process that accepts additional choices (which will guaranteed that the counter implementation shown in Fig- never be selected); for an internal choice we can substitute ure 2 truthfully reflects the counter’s value. If a bit process a process that offers fewer choices (the others will never be were not to own its $higher process (and transitively all sent) [27]. For example, the session type more significant bit processes) any assumptions it makes typedef ctr_inc2; on those processes’ state could be compromised by changes choice ctr_inc2 {
17 typedef queue; // external choice Deq, in which case it sends the label None, if it is empty, or typedef queue_elem; // internal choice Some choice queue { the label followed by the queue element, otherwise, Enq; // enqueue received value, continue and then continues as a queue.
18 ctr_test $c counter_inc2(ctr $d) { cess of which the current process is a client. Type-directed loop { switch ($c) { delegation bears resemblance to SML functors [33, 47] case Inc2: and corresponds to identity expansion in linear logic that $d.Inc; $d.Inc; eliminates the use of the identity rule at a compound type break; (ctr inc2) to uses of the identity rule at smaller types default: ctr $c <=> $d; / / type−directed delegation to ’d’ ( ). Type-directed delegation is different from the form } of delegation found in Self [58] because it does not pass } } along the original receiver of a message when delegating the message3. Moreover, Self is a dynamically-typed language, Figure 5. Type-directed code reuse: in all branches but whereas type-directed delegation uses typing information to Inc2, requests are satisfied by the process bound to $d, infer the delegating code. Our prototype compiler supports and thus process counter inc2 “inherits” code from undirected delegation, but does not yet support type-directed the process implementing its supertype ctr. delegation. We expect its support to be straightforward. 5.2 Internal Choice class dependent on its superclass. This breach gives rise to Another construct available in CLOO, but missing in exist- the fragile base class problem [45] and is also a source of ing object-oriented languages, is internal choice. In this sec- concern for object-oriented program verification [24, 43]. tion we contrast internal choice with external choice and dis- To facilitate program reasoning, CLOO only supports cuss the different characteristics of the two constructs with techniques for code reuse that respect encapsulation. A regard to program extensibility. powerful such technique is type-directed delegation. Type- Figure 6 shows an alternative implementation of the bit directed delegation combines message passing with subtyp- string implementation of a counter shown in Figure 2. The 0 ing such that a process of type σ delegates any messages processes inc and zero implement the session type bits to a process of a supertype σ that already implements the that defines the protocol of a bit string in terms of an internal requested behavior. choice. According to this protocol, a process implementing Figure 5 illustrates type-directed delegation on the ex- the session type bits can either send the label Eps, after ample of process counter inc2, which implements the which it terminates, or the label Bit, after which it sends session type ctr inc2 defined in Section 3.3. The type- the bit value and then continues as a bits process. directed delegation statement $c <=> $d in the default Unlike the external choice-based implementation, this case indicates that in all remaining branches requests to $c implementation does not represent the bit string in terms of are delegated correspondingly to $d. Because the type of bit and eps processes, but in terms of Bit and Eps mes- $c is a subtype of the type of $d, both the remaining cases sages sent to a client. The messages are sent starting with and the exact delegating code are well-defined and can be the least significant bit and ending with an Eps label. For inferred. example, the following code spawns a zero process and Interestingly, the amount of code to be written by the then a sequence of 6 inc processes with the zero process programmer in Figure 5 roughly corresponds to the one of at its end. Once the loop terminates, channel $ctr denotes declaring an appropriate subclass that implements the double the most recently spawned inc process, which will send the increment in a class-based object-oriented implementation. messages Bit, false, Bit, true, Bit, true, Eps, and Unlike inheritance, however, type-directed reuse is mediated thus the number 6: through the session type of the implementing process and bits $ctr = zero(); thus encapsulation of that process is respected. for (int i = 0; i < 6; i++) { The idea to delegate requests to another process that al- $ctr = inc($ctr); ready implements the behavior can also be employed to } achieve code reuse in the absence of a subtyping relation- Whereas processes zero and inc are the processes pro- ship. In this case, inference of the default cases and cor- ducing the stream of bit string messages, process val con- responding delegation code is no longer possible, and pro- sumes such a stream and converts the bit string received in grammers are required to provide this information explicitly. this way to its corresponding decimal number and sends that On the other hand, this “undirected” form of delegation still number along its offering channel. Process zero produces saves the actual code of the behavior to be reused and has the the empty bit string. Process inc, on the other hand, uses a advantage exactly that it does not require the two processes process that produces a stream of bit string messages repre- to be related, alleviating a process from anticipating possible senting the number n to offer a stream of bit string messages future reuse scenarios. representing the number n + 1. Delegation, type-directed and undirected, differs from channel forwarding (see Section 3.1) as it keeps the current 3 We have chosen the term “delegation” for type-directed code reuse to process alive and mainly delegates requests to another pro- avoid confusion with channel forwarding, which CLOO supports as well.
19 typedef bits; // internal choice internal-choice-based implementation because only a new choice bits { <> Eps; // send ’Eps’, terminate corresponding process has to be defined, but the session type Bit; // send ’Bit’, send bit, continue bits can be kept unchanged. On the other hand, adding a }; new variant, such as one representing a minus bit, amounts bits $zero zero() { to a non-modular change because it requires updating the $zero.Eps; bits close($zero); session type along with all its clients. } Mainstream object-oriented languages lack a correspond-
bits $succ inc(bits $ctr) { ing counterpart for CLOO’s internal choice. As a result, loop { those programming languages must encode an internal switch($ctr) { case Eps: choice indirectly in terms of an external choice. This en- wait($ctr); coding is achieved by the Visitor pattern [26], for example, $succ.Bit; send($succ, true); $succ = zero(); where the variants (data structure) to be extended with new case Bit: operations (visitor) must cater for future extensions by set- bool b = recv($ctr); if (b == false) { ting up an accept method. $succ.Bit; send($succ, true); $succ = $ctr; } else { $succ.Bit; send($succ, false); 6. Discussion } break; In this section, we discuss the role and realization of encap- }}} sulation in object-oriented languages, elaborate on linearity, $val val(bits $ctr) { and give an outlook on future work. int n = 0; int p = 1; / / = 2ˆ0 loop { 6.1 Encapsulation switch ($ctr) { case Eps: A key idea of the object-oriented paradigm is to encapsu- wait($ctr); send($val, n); late the operations and the data on which they operate in close($val); an object. Languages like Simula [19, 20] pushed this idea case Bit: bool b = recv($ctr); and the Actor model [6, 34] distilled it to its purest form by n = n + (b?1:0) * p; making message exchange the sole mechanism of computa- p = 2 * p; break; tion. In CLOO, we follow this tradition and make sure that }}} a process’ externally observable state can only be changed by means of message exchange. Since the protocol of mes- Figure 6. Alternative implementation of a bit string (see sage exchange is specified by a linear session type in CLOO, Figure 2) based on internal choice. modular reasoning about the resulting program is possible. The examples used throughout this paper even demon- strate that the notion of state loses its prominent role it takes It is instructive to compare the two implementations of in mainstream object-oriented programming languages and a bit string with each other. In a certain sense they are becomes a mere implementation detail in CLOO. This treat- “inverse” to each other. Whereas the external-choice-based ment makes it possible, for example, to have a mixed im- implementation represents the bit string in terms of bit plementation of a counter where the lower 32 bits are bit and eps processes, the internal-choice-based implementa- processes, each storing one bit, whereas the upper bits are tion represents the bit string in terms of Bit and Eps mes- stored as a single number in a nat process. sages. As a result, the labels of a choice in one implementa- In mainstream object-oriented languages, on the other tion become processes in the other implementation, and vice hand, state is an integral part of a program and special versa. provisions must be taken by the programmer to ensure that The constructs of external and internal choice lead to dif- it is appropriately encapsulated. In Java, for example, fields ferent modularizations of a program. In choosing one con- are exposed to the entire package by default. struct over the other, ease of modular extensibility plays an A similar breach of encapsulation can also be caused by important factor. If the program to be implemented is sta- inheritance. Inheritance allows a subclass to intercept code ble with regard to the operations that it should support, but inherited from its superclass. This coding pattern is typi- requires new variants in the future, external choice is prefer- cally found in programs that use open recursion for code able. Conversely, if the program is stable with regard to the reuse. Open recursion combines inheritance with dynami- variants that it should support, but requires new operations cally dispatched self-calls, allowing superclasses to invoke in the future, internal choice is preferable. customized code in, possibly yet to be written, subclasses For example, adding a new operation, such as one to de- (down-call) and subclasses to intercept inherited code (up- crease the value of a bit string, can be done modularly in the call). Whilst open recursion makes code extensible, it aggra-
20 vates the fragile base class problem and seriously endangers 6.3 Future Work encapsulation and reasoning [7]. As part of future work, we want to complement our cur- As discussed in Section 5.1, CLOO only supports tech- rent prototype compiler with subtyping and type-directed niques of code reuse that respect encapsulation. Our expe- reuse. We are currently formalizing the CLOO language. rience has shown, however, that the technique of delegation This formalization draws from existing work [55] that com- is sufficiently powerful to also accommodate the code reuse bines functional and message-passing concurrent computa- scenarios targeted by open recursion. By combining undi- tion based on linear logic. After those extensions and for- rected delegation with function invocations a similar reuse malization, we would like to tackle the introduction of poly- effect can be achieved in CLOO. Whereas delegation allows morphism in the sense of behavioral polymorphism [16] to “inheriting” unchanged code, the functions encapsulate the facilitate generic data structures and affine types [52] to al- code that would otherwise be executed in response to a self- low garbage collection of processes. call. Encapsulating that code in separate function declara- Existing work on linear session types as a prime notion of tions is necessary because linearity prevents a process from computation in functional programming languages is based sending a message to itself. on the recent discovery that linear logic [29] can be given an operational interpretation as session-typed message-passing 6.2 Linearity concurrent computation [15, 17, 60]. This discovery gives A question that naturally comes up is whether linearity is rise to a Curry-Howard correspondence between session- a too limiting restriction to implement real-world programs. typed processes and the intuitionistic linear sequent calcu- Using our prototype compiler, we have already implemented lus, such that session type constructors correspond to linear numerous programs (including object-oriented design pat- propositions, processes to proofs, and process interactions to terns) without linearity becoming an obstacle. We have made proof reductions. In future work we want to explore this cor- similar observations when experimenting with the functional respondence in our setting. We believe that the distinction language SILL [3]. Also, we find it very encouraging that between process-local state and externally observable state the Rust programming language [2] employs an affine 4 type is beneficial as it separates our language into an imperative system, which is used as the basis of a recently developed sequential and linear concurrent part. session type library for Rust [41], which has been put to Lastly, we plan to find ways of accommodating full shar- test to define and statically enforce Servo [5] communica- ing whilst upholding the guarantees of session fidelity and tion protocols. The notion of borrowing [48] implemented absence of data races and deadlocks. It seems feasible that in Rust is analogous to ownership transfer in CLOO, where a combination of existing solutions (see discussion in Sec- the channel is sent and thus “lent out” to another process to tion 6.2) can be applied to achieve this goal. A more chal- perform an operation and then sent back once the operation lenging research goal is to find a solution that sustains the is completed. Curry-Howard correspondence established between session- Given our experience and the use of linear/affine type sys- typed processes and the intuitionistic linear sequent calculus. tems both in research and practice suggests that linearity is not an actual obstacle, but the question rather becomes how 7. Related Work many programs can be elegantly expressed with this restric- tion in place. In a sense, the situation seems analogous to the In this section, we review related work. developments in pure functional programming languages, Linear Session Types As discussed in Section 6.3, there where effects were not dismissed a priori, but were accom- exists recent work that exploits the Curry-Howard corre- modated once the right abstractions were found (i.e., mon- spondence [15, 17, 60] discovered between session types ads) to integrate mutable state and I/O without compromis- and intuitionistic linear logic. Toninho et al. [55] introduce ing purity. the functional programming language SILL [3] that com- Shared channels [15, 17, 60], for example, are readily ap- bines functional and message-passing concurrent computa- plicable to our work and can be easily integrated into CLOO tion based on linear logic. Those efforts have given rise in terms of the shifting operators defined in [52]. Whilst to theories of behavioral polymorphism [16] and observa- shared channels result in process replication, they could be tional equivalence [51]. Most recently, an elegant integration combined with traditional locking primitives to share, for of synchronous and asynchronous communication has been example, a database. Achieving this form of sharing op- discovered [52]. Whereas all this research targets a purely erationally seems to be straightforward—more challenging functional setting, our work applies linear session types to is the question what its logical interpretation might be. We an imperative, object-oriented setting. However, we expect would like to investigate this question as part of future work. this existing research to offer guidance in refining our work further because it provides evidence for the robustness of 4 An affine type system only rejects the structural property of contraction, but permits weakening. As a result it allows “dropping” resources, enforc- logically justified session types and their application to pro- ing an at most once usage pattern. gramming and reasoning.
21 Session Types for Objects There exists an active line of tolerance” of aliasing, which it implements by disallowing research that introduces session types to object-oriented pro- (channel) references in the first place. The CLOO type sys- gramming languages [23] to accommodate safe, concurrent, tem, on the other hand, uses linearity to control aliasing and object-oriented computation, even in a distributed [39] or also supports session types to define and verify communica- event-driven [40] setting. Dezani-Ciancaglini et al. [23] in- tion protocols. troduce the multi-threaded language MOOSE, which ex- tends a Java-like object-oriented language with session Typestate for Objects Research on typestate [11, 21, 22, types. The authors discuss MOOSE’s type system and op- 54] approaches the idea of constraining valid sequences of erational semantics and prove progress and preservation. A message exchange between objects from a different angle. prime motivation of the work was to preserve the program- By introducing the explicit notion of a typestate and a means ming concepts of the host language and only extend it with to control aliasing (e.g., by fractional permissions [14]), pro- further functionality: “We wanted MOOSE programming grammers annotate methods with pre- and post-conditions to be as natural as possible to people used to mainstream to specify an object’s typestate on entry and on return of object-oriented languages.” ([23]). As a consequence, ses- the method. Adherence to such protocol specifications can sions are confined to an object’s methods. Our work, in con- then be checked by employing static program analysis tech- trast, equates processes with objects, which gives processes niques [12, 22]. Traditionally, typestate has been used to ex- first-class citizenship and makes session types become the press protocols in a sequential setting, but extensions to a types of objects. concurrent setting have been elaborated [53]. Gay et al. [28] address the limited scope of MOOSE’s sessions and allow sessions to extend over several methods. In the distributed, object-oriented programming language 8. Conclusions the authors describe, a channel can even be stored in an object’s field. The main focus of the work, however, is the In this paper, we take a fresh look at object-oriented pro- specification and verification of communication protocols, gramming. Starting with the seminal ideas that objects en- which is carried out in a sequential setting. capsulate the operations along with the data on which they operate, that message exchange is the sole means by which Actors and Message-Passing Concurrency Our work objects alter state, and that objects can simultaneously ex- shares with the Actor model [6, 34] the idea that message change messages, we derive a new model of concurrent exchange should be the sole means of externally observable object-oriented programming that internalizes those ideas. computation. The Actor model has lead to various imple- We have implemented this model in our prototypical lan- mentations and has also been integrated into mainstream guage CLOO (Concurrent Linear Object-Orientation). object-oriented languages [31] in terms of libraries [32, 57]. Our model of object-oriented computation takes linear Actors, however, are traditionally untyped, making it im- session types as its foundation. In the paper we show, based possible to specify and verify the protocols emerging from on various programming examples, that object-oriented pro- message exchange. Actors do not even restrict message ar- gramming arises naturally from linear session-based com- rival order. munication. According to this correspondence, objects can Neykova and Yoshida [50] target the expression of the be viewed as processes, references as channels, and method protocols for actor coordination. The authors introduce a invocations as label selection of external choices. We show Python library that allows the expression of actor protocols that labels are dynamically dispatched and that subtyp- based on multiparty session type protocols [38]. Protocols ing arises between different forms of external and internal are expressed in the specification language Scribble [4] as choices. Our model also enables new forms of expression annotations of the Python code. Protocol compliance can such as type-directed reuse and internal choice that are not then be checked at run-time, using the Scribble toolchain. available in current object-oriented languages. From its message-passing approach to concurrency CLOO Thanks to its foundation on linear session types, our lan- also relates to the Erlang [9] programming language. Erlang guage guarantees session fidelity and absence of data races is a dynamically-typed functional language that uses asyn- and deadlocks. A formal proof of those guarantees is in chronous message passing to achieve concurrency in a pos- progress. An important concern in the development of our sibly distributed setting. CLOO, on the other hand, explores language was to accommodate a genuine object-oriented asynchronous message passing in an object-oriented impera- style while at the same time facilitate program reasoning. tive setting and uses linear session types to statically guaran- For this reason our language only supports code reuse tech- tee session fidelity and absence of data races and deadlocks. niques that respect encapsulation, a characteristics that does Similarly, CLOO is related to occam-pi [1], which com- not hold for current mainstream object-oriented languages. bines the concepts of CSP [35] with the π-calculus [46]. In future work, we intend to investigate the logical founda- Processes in Occam-pi encapsulate their state and commu- tion of our language and evaluate its support in the construc- nicate via message exchange. Occam-pi further has a “zero- tion of correct, concurrent programs.
22 Acknowledgments (ESOP), volume 7792 of Lecture Notes in Computer Science, This material is based upon work supported by the Na- pages 330–349. Springer, 2013. tional Science Foundation under Grant No. CNS-1423168. [17] L. Caires, F. Pfenning, and B. Toninho. Linear logic proposi- We would like to thank Henry DeYoung for discussions on tions as session types. Mathematical Structures in Computer type-directed delegation and the anonymous reviewers for Science, 2013. To appear. Special Issue on Behavioural Types. their helpful comments. [18] D. Clarke, J. Potter, and J. Noble. Ownership types for flexible alias protection. In 13th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and References Applications (OOPSLA’98), pages 48–64. ACM, 1998. [1] occam-pi: blending the best of CSP and the pi-calculus. [19] O.-J. Dahl and K. Nygaard. SIMULA - an ALGOL-based www.cs.kent.ac.uk/projects/ University of Kent. simulation language. Communications of the ACM, 9(9):671– ofa/kroc/ . 678, 1966. [2] Rust language. www.rust-lang.org. [20] O.-J. Dahl, B. Myhrhaug, and K. Nygaard. SIMULA 67 [3] Sill. https://github.com/ISANobody/sill. Common Base Language. Norwegian Computing Center, [4] Scribble. http://www.scribble.org. 1968. [5] Servo project. https://github.com/servo/servo. [21] R. DeLine and M. Fahndrich.¨ Enforcing high-level protocols in low-level software. In ACM SIGPLAN Conference on [6] G. A. Agha. Actors: A Model of Concurrent Computation in Programming Language Design and Implementation (PLDI), Distributed Systems. MIT Press Series in Artificial Intelli- pages 59–69, 2001. gence. MIT Press, 1990. ISBN 978-0-262-01092-4. [22] R. DeLine and M. Fahndrich.¨ Typestates for objects. In [7] J. Aldrich and K. Donnelly. Selective open recursion: Mod- 18th European Conference on Object-Oriented Programming ular reasoning about components and inheritance. In 3th (ECOOP’04), volume 3086 of Lecture Notes in Computer International Workshop on Specification and Verification of Science, pages 465–490. Springer, 2004. Component-Based Systems (SAVCBS), 2004. [8] D. J. Armstrong. The quarks of object-oriented development. [23] M. Dezani-Ciancaglini, D. Mostrous, N. Yoshida, and Communications of the ACM, 49(2):123–128, February 2006. S. Drossopoulou. Session types for object-oriented languages. In 20th European Conference on Object-Oriented Program- [9] J. Armstrong, R. Virding, C. Wikstrom,¨ and M. Williams. ming (ECOOP), volume 4067 of Lecture Notes in Computer Concurrent programming in ERLANG. Prentice Hall, 2nd Science, pages 328–352. Springer, 2006. edition, 1996. [24] S. Drossopoulou, A. Francalanza, P. Muller,¨ and A. Summers. [10] R. Arnold, F. Pfenning, and R. Simmons. C0: Specification A unified framework for verification techniques for object and verification in introductory computer science. http: invariants. In 22nd European Conference on Object-Oriented //c0.typesafety.net, 2010. Programming (ECOOP’08), volume 5142 of Lecture Notes in [11] K. Bierhoff and J. Aldrich. Modular typestate checking of Computer Science, pages 412–437. Springer, 2008. aliased objects. In 22nd Annual ACM SIGPLAN Conference [25] C. Flanagan, S. N. Freund, and J. Yi. Velodrome: a sound on Object-Oriented Programming, Systems, Languages, and and complete dynamic atomicity checker for multithreaded Applications (OOPSLA’07), pages 301–320. ACM, 2007. programs. In ACM SIGPLAN Conference on Programming [12] K. Bierhoff, N. E. Beckman, and J. Aldrich. Practi- Language Design and Implementation (PLDI), pages 293– cal API protocol checking with access permissions. In 303. ACM, 2008. 23rd European Conference on Object-Oriented Programming [26] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. De- (ECOOP) , pages 195–219, 2009. sign Patterns: Elements of Reusable Object-Oriented Soft- [13] C. Boyapati, R. Lee, and M. C. Rinard. Ownership types for ware. Addison-Wesley, 1995. safe programming: Preventing data races and deadlocks. In [27] S. J. Gay and M. Hole. Subtyping for session types in the 17th Annual ACM SIGPLAN Conference on Object-Oriented π-calculus. Acta Informatica, 42(2–3):191–225, 2005. Programming, Systems, Languages, and Applications (OOP- SLA’02), pages 211–230, New York, NY, USA, 2002. ACM. [28] S. J. Gay, V. T. Vasconcelos, A. Ravara, N. Gesbert, and A. Z. Caldeira. Modular session types for distributed object- [14] J. Boyland. Checking interference with fractional permis- orientedriented programming. In 37th ACM SIGPLAN- sions. In 10th International Symposium on Static Analysis SIGACT Symposium on Principles of Programming Lan- (SAS), pages 55–72, 2003. guages (POPL’05), pages 299–312, 2010. [15] L. Caires and F. Pfenning. Session types as intuitionistic lin- [29] J.-Y. Girard. Linear logic. Theoretical Computer Science, 50: ear propositions. In 21st International Conference on Con- 1–102, 1987. currency Theory (CONCUR), volume 6269 of Lecture Notes in Computer Science, pages 222–236. Springer, 2010. [30] A. Goldberg and D. Robson. Smalltalk-80: The Language and [16] L. Caires, J. A. Perez,´ F. Pfenning, and B. Toninho. Behav- Its Implementation. Addison-Wesley, 1983. ioral polymorphism and parametricity in session-based com- [31] P. Haller. On the integration of the actor model into main- munication. In 22nd European Symposium on Programming stream technologies: A scala perspective. In 2nd International
23 Workshop on Programming based on Actors, Agents, and De- [46] R. Milner. Communicating and Mobile Systems: the π- centralized Control (AGERE!), pages 1–6. ACM, 2012. Calculus. Cambridge University Press, 1999. [32] P. Haller and M. Odersky. Scala actors: Unifying thread- [47] R. Milner, M. Tofte, R. Harper, and D. MacQueen. Definition based and event-based programming. Theoretical Computer of Standard ML (Revised). MIT Press, 1997. Science, 410(2-3):202–220, 2009. [48] K. Naden, R. Bocchino, J. Aldrich, and K. Bierhoff. A type [33] R. Harper and M. Lillibridge. A type-theoretic approach to system for borrowing permissions. In 39th ACM SIGPLAN- higher-order modules with sharing. In 21th ACM SIGPLAN- SIGACT Symposium on Principles of Programming Lan- SIGACT Symposium on Principles of Programming Lan- guages (POPL), pages 557–570. ACM, 2012. guages (POPL), pages 123–137. ACM, 1994. [49] M. Naik, A. Aiken, and J. Whaley. Effective static race detec- tion for Java. In ACM SIGPLAN Conference on Programming [34] C. Hewitt. Viewing control structures as patterns of passing Language Design and Implementation (PLDI), pages 308– messages. Artificial Intelligence, 8(3):323–364, 1977. 319. ACM, 2006. [35] C. Hoare. Communicating sequential processes. Communica- [50] R. Neykova and N. Yoshida. Multiparty session actors. In 16th tions of the ACM, 21(8):666–677, 1978. International Conference on Coordination Models and Lan- [36] K. Honda. Types for dyadic interaction. In 4th Interna- guages (COORDINATION), volume 8459 of Lecture Notes in tional Conference on Concurrency Theory (CONCUR), vol- Computer Science, pages 131–146. Springer, 2014. ume 715 of Lecture Notes in Computer Science, pages 509– [51] J. A. Perez,´ L. Caires, F. Pfenning, and B. Toninho. Linear 523. Springer, 1993. logical relations and observational equivalences for session- [37] K. Honda, V. T. Vasconcelos, and M. Kubo. Language primi- based concurrency. Information and Computation, 239:254– tives and type discipline for structured communication-based 302, 2014. programming. In 7th European Symposium on Programming [52] F. Pfenning and D. Griffith. Polarized substructural ses- (ESOP), volume 1381 of Lecture Notes in Computer Science, sion types. In 18th International Conference on Foundations pages 122–138. Springer, 1998. of Software Science and Computation Structures (FoSSaCS), [38] K. Honda, N. Yoshida, and M. Carbone. Multiparty volume 9034 of Lecture Notes in Computer Science, pages 3– asynchronous session types. In 35th ACM SIGPLAN- 22. Springer, 2015. SIGACT Symposium on Principles of Programming Lan- [53] S. Stork, K. Naden, J. Sunshine, M. Mohr, A. Fonseca, guages (POPL), pages 273–284. ACM, 2008. P. Marques, and J. Aldrich. Aeminium: A permission-based concurrent-by-default programming language approach. ACM [39] R. Hu, N. Yoshida, and K. Honda. Session-based distributed Transactions on Programming Languages and Systems programming in Java. In 22nd European Conference on (TOPLAS), 36(1):2:1–2:42, 2014. ISSN 0164-0925. Object-Oriented Programming (ECOOP), volume 5142 of Lecture Notes in Computer Science, pages 516–541. Springer, [54] R. E. Strom and S. Yemini. Typestate: A programming lan- 2008. guage concept for enhancing software reliability. IEEE Trans- actions on Software Engineering (TSE), 12(1):157–171, 1986. [40] R. Hu, D. Kouzapas, O. Pernet, N. Yoshida, and K. Honda. Type-safe eventful sessions in java. In 24th European Con- [55] B. Toninho, L. Caires, and F. Pfenning. Higher-order pro- ference on Object-Oriented Programming (ECOOP), volume cesses, functions, and sessions: a monadic integration. In 22nd European Symposium on Programming (ESOP) 6183 of Lecture Notes in Computer Science, pages 329–353. , volume Lecture Notes in Computer Science Springer, 2010. 7792 of , pages 350–369. Springer, 2013. [41] T. B. L. Jespersen, P. Munksgaard, and K. F. Larsen. Session [56] B. Toninho, L. Caires, and F. Pfenning. Corecursion and non- types for rust. In 11th ACM SIGPLAN Workshop on Generic divergence in session types. In 9th International Symposium Programming (WGP), 2015. on Trustworthy Global Computing (TGC), volume 8902 of [42] A. Kay. On the meaning of object-oriented program- Lecture Notes in Computer Science, pages 159–175. Springer, ming. http://www.purl.org/stefan_ram/pub/ 2014. doc_kay_oop_en, July 2003. Email exchange. [57] Typesafe. Akka framework. http://akka.io. [43] G. T. Leavens, K. R. M. Leino, and P. Muller.¨ Specification [58] D. Ungar and R. B. Smith. Self: The power of simplicity. In and verification challenges for sequential object-oriented pro- 2nd Annual ACM SIGPLAN Conference on Object-Oriented grams. Formal Aspects of Computing, 19(2):159–189, 2007. Programming, Systems, Languages, and Applications (OOP- [44] N. D. Matsakis and T. R. Gross. A time-aware type system SLA’87), pages 227–242. ACM, 1987. for data-race protection and guaranteed initialization. In 25th [59] M. Vaziri, F. Tip, and J. Dolby. Associating synchronization Annual ACM SIGPLAN Conference on Object-Oriented Pro- constraints with data in an object-oriented languages. In gramming, Systems, Languages, and Applications (OOPSLA), 33rd ACM SIGPLAN-SIGACT Symposium on Principles of pages 634–651. ACM, 2010. Programming Languages (POPL’06), pages 334–345. ACM, 2006. [45] L. Mikhajlov and E. Sekerinski. A study of the fragile base class problem. In 12th European Conference on Object- [60] P. Wadler. Propositions as sessions. In 17th ACM SIG- Oriented Programming (ECOOP), Lecture Notes in Com- PLAN International Conference on Functional Programming puter Science, pages 355–382. Springer, 1998. (ICFP), pages 273–286. ACM, 2012.
24