A unified design of capsules

The process of reading, writing, and reasoning about concurrent programs benefits from better abstractions for concurrency than what many common languages, such as Java, offer. Capsule-oriented programming and the Panini language utilize the idea of combining state and control within a linguistic mechanism along with asynchronous message passing to provide sequentially trained programmers with an actor-like language that preserves the expected sequential semantics. The initial design of the Panini language splits the world into two distinct elements – capsules and systems. A capsule acts as the unit of both modularity and concurrency in the program. A system acts as the sole point of composition for capsule instances. The problem is that the dichotomy between systems and capsules leads to uncomposable and non-modular programs. The connections between capsule instances in a system declaration are fixed at exactly one point and all capsules instances in program must be declared and connected to each other at a single block of code. This thesis will explore the implications on modularity and reuse of systems when a basic design decision – separating capsules and systems – is relaxed to allow a capsule to declare an internal composition of other capsule instances

Modularizing Crosscutting Concerns With Ptolemy

In this demonstration we show our language Ptolemy, which allows for separation of crosscutting concerns while maintaining modular reasoning. We demonstrate the benefits of Ptolemy over existing aspect-oriented languages and implicit invocation designs. Ptolemy\u27s quantified, typed events provide a flexible quantification mechanism that acts as a declarative interface between object-oriented code and crosscutting code. Events are announced explicitly and declaratively. Event types allow for compile-time errors and avoid the fragile pointcut problem of aspect-oriented languages. The interface provided by event types also allows for modular reasoning, without considering all aspects in the system. The declarative event announcement allows avoiding writing tedious and error-prone boiler-plate code that implicit invocation designs require. We demonstrate several realistic examples that showcase the features of the Ptolemy language and show use of Ptolemy\u27s compiler. The demonstrated compiler is built on top of the OpenJDK Java compiler (javac), providing full backwards compatibility with existing Java sources as well as ease of integration into the existing tool chains. We show how to integrate the compiler into both existing Ant and Eclipse builds

Modularizing Crosscutting Concerns With Ptolemy

This tutorial will provide an introduction to Ptolemy. Ptolemy is a programming language whose goals are to improve a software engineer\u27s ability to separate conceptual concerns, while preserving encapsulation of object-oriented code and the ability of programmers to modularly reason about their code. In particular, Ptolemy\u27s features are useful towards modularization of cross-cutting concerns. A cross-cutting concern is a requirement whose implementation is spread across and mixed with the code of other requirements. There has been attempts to improve separation of cross-cutting concerns, e.g. by aspect-oriented and implicit-invocation languages, but none give software developers textual separation of concerns and modular reasoning at the same time. Ptolemy has both these properties important for scalable software engineering. Ptolemy\u27s event types provide a well-defined interface between object-oriented code and cross-cutting code. This in turn enables separate type-checking and compilation. Ptolemy also provides a novel and practical specification mechanism that we call translucid contracts. A translucid contracts allows developers to reason about the control effects of the object-oriented code and cross-cutting code modularly. This tutorial will proceed by discussing the goals of the Ptolemy programming language. We will then discuss Ptolemy\u27s programming features and its specification features by way of several handson exercises. We will conclude with pointers to ongoing work on design, implementation and verification of Ptolemy programs