What is Ptolemy?

Ptolemy is a programming language whose goals are to improve a software engineer's ability to separate conceptual concerns. In particular, Ptolemy's features are useful towards modularization of crosscutting concerns. A key difference between Ptolemy and other technologies to separate conceptual concerns such as AspectJ is that Ptolemy strives to balance separation of crosscutting concerns and modular understanding and reasoning about concerns. It is our motto that "one shall not have to choose between modular reasoning and separation of crosscutting concerns."

Ptolemy Programming Language History

Ptolemy combines best ideas from implicit invocation (II) design style and aspect-oriented (AO) languages in the style of AspectJ. For a brief background on implicit invocation (II) design style and its limitations see here. For a brief background on aspect-oriented languages and their limitations see here. Briefly, Ptolemy was designed to solve several problems with AO and II paradigms such as quantification failure, fragile pointcuts, limited context information, lack of modular reasoning and understanding. For a more detailed motivation of the language design, please see our web-page on this topic here.

Design Goals

Ptolemy has the following main design goals:

• Enable modularization of crosscutting concerns, while preserving encapsulation of existing object-oriented code,
• enable well-defined interfaces between object-oriented code and crosscutting code, and
• enable separate type-checking, separate compilation, and modular reasoning of both object-oriented and crosscutting code.

All these goals are important for scalability of software development processes but harder to achieve in current AO languages in the style of AspectJ.

Getting Started

The Ptolemy compiler offers support for compiling and running programs from command-line as well as from within Ant. To get started with setting up an environment for running Ptolemy programs please see our page on installing and running the compiler.

Once you have downloaded and installed the compiler, you could look at the examples included in the distribution. Or alternatively, you could also consult the programming guide for Ptolemy.

Motivation

The objective of both implicit invocation (II) and aspect-oriented (AO) languages is to improve a software engineer's ability to separate conceptual concerns. The problem that they address is that all dimensions of design decisions, or concerns, are not amenable to modularization by a single dimension of decomposition. Instead, some concerns cut across the dominant dimension of decomposition. These approaches aim to improve the separation of these types of concerns thereby enhancing modularity.

The key idea in II languages is that some interfaces declare events, allowing one set of modules to contain code that dynamically and explictly announces events, while a second set of modules dynamically registers methods, called handlers, to receive calls (the implicit invocations) when events are announced. The two sets of modules are independent of each other and need only share the event interface declarations.

In AO languages such as AspectJ events (called "join points") are pre-defined by the language as certain kinds of standard actions (such as method calls) in a program's execution. AO events are all implicitly announced. Pointcut descriptions (PCDs) are used to declaratively register handlers (called "advice") with sets of events. Using PCDs to register a handler with an entire set of events, called quantification, is a key idea in AO languages that has no counterpart in II languages. A language's set of PCDs and its set of events form its event model (in AO terms this is a "join point model").

II Languages have three limitations. First, they require complex event declaration, announcement, and registration code scattered across the system. Second, the ability to replace the code for an event (what AO calls "around advice"), is not available, without unnecessarily complex emulation code (to simulate closures in languages such as Java and C#). Third, quantification is not easy, since no abstraction like PCDs is available. Instead, a non-trivial strategy, such as a subscription registry, is needed.

AO languages also have limitations, primarily because most current event models use lexical PCDs. Such PCDs use patterns of names; for example, call(run*(..)) describes a set of call events in which the name of the called method starts with run. Lexical PCDs are fragile, exhibit quantification failures, and make it unnecessarily hard to uniformly access information from an event's context.

Figure 1: Overview of the coupling structure in Observer design pattern, aspect-oriented programming, and Ptolemy's quantified event types.

Ptolemy solves the problems with II and AO languages using quantified, typed events. Ptolemy's event types are named when they are declared, and these names can be used in quantification. An event type p also declares the types of information communicated between announcements of events of type p and handler methods.

Page last modified on $Date: 2011/07/31 21:33:56 $