Paper presented at the 9th ACM International Conference on Generative Programming and Component Engineering (GPCE 2010).
Reference and paper available here.

Aspect-oriented programming provides a convenient high-level model to define several kinds of dynamic analyses, in particular thanks to recent advances in exhaustive weaving in core libraries. Casting dynamic analyses as aspects allows the use of a single weaving infrastructure to apply different analyses to the same base program, simultaneously. However, even if dynamic analysis as- pects are mutually independent, their mere presence perturbates the observations of others: this is due to the fact that aspectual compu- tation is potentially visible to all aspects. Because current aspect composition approaches do not address this kind of computational interference, combining different analysis aspects yields at best un- predictable results. It is also impossible to flexibly combine various analyses, for instance to analyze an analysis aspect. In this paper we show how the notion of execution levels makes it possible to effectively address these composition issues. In order to realize this approach, we explore the practical and efficient integration of exe- cution levels in a mainstream aspect language, AspectJ. We report on a case study of composing two out-of-the-box analysis aspects in a variety of ways, highlighting the benefits of the approach.

Best paper award of the 9th ACM International Conference on AOSD.
Reference and paper available here.

In aspect-oriented programming languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression in all cases, and give advanced programmers the means to override this default using level shifting operators. We formalize the semantics of our proposal, and provide an implementation. This work recognizes that different aspects differ in their intended nature, and shows that structuring execution contexts helps tame the power of aspects and metaprogramming.

The following artefacts are provided:

• the executable reduction semantics of the language in PLT Redex
• the implementation of AspectScheme* (ie. AspectScheme modified with execution levels)

All the code has been developed and tested under DrScheme 4.2.1 using PLT Scheme and PLT Redex.

See also the AspectScript website. AspectScript relies at its core on the model presented in this paper.

Here are the executable reduction semantics of Execution Levels with Exceptions, using PLT Redex. This is an extension submitted to FOAL 2011.

Paper accepted at the Scheme and Functional Programming workshop 2009. Reference and paper available here.

superseded by the AOSD.10 paper (above).

Paper presented at the 5th ACM Dynamic Languages Symposium 2009.
Reference and paper available here.

Traditional treatment of scoping in programming languages considers two opposite semantics: static scoping, where the scope of a binding is a block of program text, and dynamic scoping, where a binding is in effect during the whole reduction of an expression to a value. Static scoping and dynamic scoping are however but two points in the design space of scoping mechanisms. As a result, most proposed language mechanisms that rely on some notion of scoping, such as variable bindings of course, but also more exotic ones like aspects and mixin layers, adopt either one or the other semantics. As it turns out, these two semantics are sometimes too extreme, and a mixture of both is needed. To achieve this, language designers and/or programmers have to resort to ad hoc solutions. We present a general scoping model that simply expresses static and dynamic scoping, and that goes further by allowing fine-grained exploration of the design space of scoping. The model, called scoping strategies, gives precise control over propagation and activation of language mechanisms. While we have already studied it for aspects, we hereby show that the model is not restricted to aspects, by treating in depth its application to the most standard kind of adaptation: variable bindings. We also briefly discuss its application to mixin layers, and program monitoring. We believe that research in programming language constructs can benefit from a more flexible notion of scoping that goes beyond the static/dynamic dichotomy.

The code of the interpreter mentioned in the paper is available here.

• Interpreter of bindings with scoping strategies

All the code has been developed and tested under DrScheme 4.1 using PLT Scheme.

Paper presented at the 7th ACM International Conference on AOSD.
Reference and paper available here.

Several aspect languages and frameworks have recognized the need for dynamic deployment of aspects. However, they do not provide sufficiently expressive means to precisely specify the scope of deployed aspects. As a result, programmers have to resort to unnecessarily complex pointcut definitions that hinder the reuse potential of aspects.

To address the issue of precise and expressive scoping of aspects at deployment time, we propose deployment strategies for parameterized dynamic aspect deployment. This novel mechanism gives full control over the propagation of the aspect on the call stack and within created objects or functions, and permits a deployment-specific refinement of its pointcuts.

We discuss and illustrate the gain in expressiveness, and provide the operational semantics of deployment strategies with Scheme interpreters, for both functional and object-oriented based aspect languages.

The code of the interpreters described in the paper is available here.

• Interpreter of simplified AspectScheme
• Interpreter of deployment strategies in a functional language
• Interpreter of deployment strategies in an object-oriented language (includes the examples used in the paper)

All the code has been developed and tested under DrScheme v372 using PLT MzScheme.

See also: the original Aspect SandBox interpreters.

Paper presented at the 8th ACM International Conference on AOSD.
Reference and paper available here.

Dynamic deployment of aspects brings greater flexibility and reuse potential, but requires proper means for scoping aspects. Scoping issues are particularly crucial in a distributed context: adequate treatment of distributed scoping is necessary to enable the propagation of aspect instances across host boundaries and to avoid inconsistencies due to unintentional spreading of data and computations in a distributed system.

We motivate the need for expressive scoping of dynamically-deployed distributed aspects by an analysis of the deficiencies of current approaches for distributed aspects. Extending recent work on deployment strategies for non-distributed aspects, we then introduce a set of high-level strategies for specifying locality of aspect propagation and activation, and illustrate the corresponding gain in expressiveness. We present the operational semantics of our proposal using Scheme interpreters, first introducing a model of distributed aspects that covers the range of current proposals, and then extending it with dynamic aspect deployment. This work shows that, given some extensions to their original execution model, deployment strategies are directly applicable to the expressive scoping of distributed aspects.

The code of the interpreter described in the paper is available here.

All the code has been developed and tested under DrScheme v4.1 using PLT Scheme.

Best paper award of the Brazilian Symposium on Programming Languages 2008.
Also appeared in the Journal of Universal Computer Science.
Reference and paper available here.

Aspect languages provide different mechanisms to control when an aspect should apply based on properties of the execution context. They however fail to explicitly identify and cleanly capture a property as basic as that of reentrancy. As a result, aspect developers have to resort to low-level and complex pointcut descriptions that are error prone and hamper the understandability of aspect definitions. We analyze the issue of aspect reentrancy, illustrate how current languages fail to properly support it, and define a new linguistic construct to control aspect reentrancy. Considering aspect reentrancy from the start in the design of an aspect language simplifies the task of aspect programmers by raising the level of abstraction of aspect definitions.

Paper presented at the ACM Dynamic Languages Symposium 2008.
Reference and paper available here.

Context-oriented programming proposes to treat execution context explicitly and to provide means for context-dependent adaptation at runtime. There are many mechanisms that can be used to make either variable bindings or application code adapt dynamically, like dynamically-scoped variables, dynamic layer activation, and contextual dispatch. There are no means however, to make actual values be context-dependent. This means that side effects engendered by dynamically-activated adaptations are potentially global.

We propose contextual values: values that actually depend on the context in which they are looked at and modified. We explore how contextual values can be provided, either as a simple library or directly into the language through different designs, for which we provide the operational semantics in the form of Scheme interpreters. Being able to scope side effects to certain contexts is a step forward for context-oriented programming, and can have interesting applications in other areas like security and dynamic software evolution.

The code of the definition of contextual values, as well as of Scheme interpreters for contextual values, is available here.

• Scheme definition of explicit contextual values
• Interpreter of implicit contextual values
• Interpreter of implicit contextual values with scoped assignment regions

All the code has been developed and tested under DrScheme v372 using PLT MzScheme.

questions, problems, feedback: Éric Tanter