Effective Aspects: A Typed Monadic Embedding of Pointcuts and Advice

TL;DR: This work brings type-based reasoning about effects for the first time in the pointcut/advice model, in a framework that is both expressive and extensible; thus allowing development of robust aspect-oriented systems as well as being a useful research tool for experimenting with new aspect semantics.

Abstract: Aspect-oriented programming (AOP) aims to enhance modularity and reusability in software systems by offering an abstraction mechanism to deal with crosscutting concerns. However, in most general-purpose aspect languages aspects have almost unrestricted power, eventually conflicting with these goals. In this work we present Effective Aspects: a novel approach to embed the pointcut/advice model of AOP in a statically typed functional programming language like Haskell. Our work extends EffectiveAdvice, by Oliveira, Schrijvers, and Cook; which lacks quantification, and explores how to exploit the monadic setting in the full pointcut/advice model. Type soundness is guaranteed by exploiting the underlying type system, in particular phantom types and a new anti-unification type class. Aspects are first-class, can be deployed dynamically, and the pointcut language is extensible, therefore combining the flexibility of dynamically typed aspect languages with the guarantees of a static type system. Monads enables us to directly reason about computational effects both in aspects and base programs using traditional monadic techniques. Using this we extend Aldrich’s notion of Open Modules with effects, and also with protected pointcut interfaces to external advising. These restrictions are enforced statically using the type system. Also, we adapt the techniques of EffectiveAdvice to reason about and enforce control flow properties. Moreover, we show how to control effect interference using the parametricity-based approach of EffectiveAdvice. However, this approach falls short when dealing with interference between multiple aspects. We propose a different approach using monad views, a recently developed technique for handling the monad stack. Finally, we exploit the properties of our monadic weaver to enable the modular construction of new semantics for aspect scoping and weaving. These semantics also benefit fully from the monadic reasoning mechanisms present in the language. This work brings type-based reasoning about effects for the first time in the pointcut/advice model, in a framework that is both expressive and extensible; thus allowing development of robust aspect-oriented systems as well as being a useful research tool for experimenting with new aspect semantics.

Summary

1 Introduction

• Aspect-oriented programming languages support the modular definition of crosscutting concerns through a join point model [19].
• This work proposes Effective Aspects: a lightweight, full-fledged embedding of aspects in Haskell, that is typed and monadic.
• The authors mainly expand on using types to reason about aspect interference (Section 7).
• In short, the authors can generalize the interference combinators of EffectiveAdvice [28] in the context of pointcuts and advice (Sect. 6).
• Second, because the authors embed a monadic weaver, they can modularly extend the aspect language semantics.

2 Prelude: Overview of Monadic Programming

• To make this work self-contained and to cater to readers not familiar with monads, the authors present a brief overview of the key concepts of monadic programming in Haskell used throughout this paper.
• More precisely, the authors introduce the state and error monad transformers, and the mechanisms of explicit and implicit lifting in the monad stack.
• The reader is only expected to know basic Haskell programming and to understand the concept of type classes.
• Readers already familiar with monadic programming can safely skip this section.

2.1 Monads Basics

• Monads [27,46] are a mechanism to embed and reason about computational effects such as state, I/O, or exception-handling in purely functional languages like Haskell.
• Monad transformers [22] allow the modular construction of monads that combine several effects.
• Monadic programming in Haskell is provided by the Monad Transformers Library (known as MTL), which defines a set of monad transformers that can be flexibly composed together.
• The precise meanings for return and >>= are specific to each monad.
• Haskell provides the do-notation, which directly 4 translates to chained applications of >>=.

2.2 Plain Monadic Programming

• To illustrate monadic programming the authors first describe the use of the state monad transformer StateT , denoted as ST, whose computational effect is to thread a value with read-write access.
• In addition, functions getST and putST allow to retrieve and update the state inside a computation, respectively5.
• The authors also define runM 1, which initializes the queue with an empty list, and returns only the resulting value of a computation in M1.
• The straightforward definition of dequeue 2 fails with a typing error: dequeue 2 ::M2 Explicit Lifting in the Monad Stack Using lift one can reuse a function intended for an inner layer on the stack, like throwET.the authors.

2.3 Polymorphism on the Monad Stack

• To address the coupling of functions with particular monad stacks and to expand the notion of monads as a uniform interface for computational effects, the MTL defines a set of type classes associated to particular effects.
• This way, monadic functions can impose constraints in the monad stack using these type classes instead of relying on a specific stack.
• The MonadError type class, denoted as EM, defines the standard interface for error-handling operations, with ET as its canonical instance.
• The MTL defines implicit liftings between its transformers, by defining several class instances for each of them.
• The major limitation of implicit liftings is that it only chooses the first layer of a given effect.

3 Introducing Aspects

• The fundamental premise for aspect-oriented programming in functional languages is that function applications need to be subject to aspect weaving.
• Opening all applications is more flexible, but can lead to fragile aspects and unwanted encapsulation breaches.
• The authors will come back to obliviousness in Sect. 9.3, showing how different answers can be provided within the context of their proposal.
• The approach to introduce aspects in a pure functional programming language like Haskell can be realized without considering effects.
• As shown in this example, aspects consist of a pointcut/advice pair and are created with aspect , and deployed with deploy .

3.1 Join Point Model

• The support for crosscutting provided by an aspect-oriented programming language lies in its join point model [24].
• A pointcut simply returns a boolean to indicate whether it matches the given join point.
• 7 Haskell provides the Typeable class to introspect monomorphic types.
• 10 Pointcut Language Note that in pcCall the authors also need to perform a type comparison, using compareType.
• The authors defer the detailed definition of Aspect with its type class constraints to Sect. 4.2, when they address the issue of safe pointcut/advice binding.

3.2 Aspect Deployment

• Aspect Environment Different scoping strategies are possible when dealing with dynamic deployment [40].
• There are a number of design options for the aspect environment, depending on the kind of aspect deployment that is desired.
• Following the Reader monad, the authors can provide a fixed aspect environment, and add the ability to deploy an aspect for the dynamic extent of an expression, similarly to the local method of the Reader monad.
• To define the AT transformer the authors reuse the ST data constructor, because the AT transformer is essentially a state transformer (Sect. 2.2) that threads the aspect environment.
• In Haskell an existentially-quantified data type is declared using ∀ before the data constructor 10 Because the authors cannot anticipate a fixed set of class constraints for deployed aspects, they left the type parameters unconstrained.

3.3 Aspect Weaving

• The authors introduce a type class OpenApp that declares the # operator.
• The join point is then used to determine which aspects in the environment match, produce a new function that combines all the applicable advices, and apply that function to the original argument.
• The weave function is defined recursively on the aspect environment.
• The operation unsafeCoerce of Haskell is unsafe and can yield segmentation faults or arbitrary results.
• The authors instead make aspects type safe such that they can prove that the particular use of unsafeCoerce in apply_adv is always safe.

4.1 Typing Pointcuts

• The intermediary between a join point and an advice is the pointcut, whose proper typing is therefore crucial.
• The use of phantom type variables to type embedded languages was first introduced by Leijen and Meijer to type an embedding of SQL in Haskell [21]; it makes it possible to “tag” extra type information on data.
• Because a pointcut potentially matches many join points of different types, the matched type must be a more general type.
• Another more general candidate is a → m b, but the least general type conveys more precise information.

4.2 Typing Aspects

• The main typing issue the authors have to address consists in ensuring that a pointcut/advice binding is type safe, so that the advice application does not fail.
• A first idea to ensure that the pointcut/advice binding is type safe is to require the matched type of the pointcut and the advised type of the advice to be the same (or rather, unifiable): -- wrong!.
• This approach can however yield unexpected behavior.
• When evaluated, the behavior of program is 17 undefined because the advice is unsafely applied with an argument of type [Bool ], for which toUpper is undefined.
• The authors formally prove this in the following section.

5 Typing Aspects, Formally

• The authors now formally prove the safety of their approach.
• The authors start briefly summarizing the notion of type substitutions and the is less general relation between types.
• Note that the authors do not consider type class constraints in the definition.
• Then the authors describe a novel anti-unification algorithm implemented with type classes, on which the type classes LessGen and LeastGen are based.
• The authors finally prove pointcut and aspect safety, and state their main safety theorem.

5.1 Type Substitutions

• In this section the authors summarize the definition of type substitutions and introduce formally the notion of least general type in a Haskell-like type system (without ad-hoc polymorphism).
• Substitutions are always applied simultaneously on a type.
• Substitution is extended pointwise for typing environments in the following way: σ(xi : ti)i∈N = (xi : σti)i∈N.
• Observe that defines a partial order on types (modulo α-renaming).

5.2 Statically Computing Least General Types

• To do this the authors encode an anti-unification algorithm at the type level, exploiting the type class mechanism.
• For simplicity the authors omit the rules for analyzing type representations.
• The component-wise application of constraints is done from left to right, starting from sub- stitution σ0 and extending it to the resulting substitution σn.
• In the rule defined in lines 10-13 the goal is to extend σin with the mapping c 7→ (a, b) such that σoutc = (a, b), while preserving the injectivity of the substitution (see next proposition).
• By induction on the type representation of a and b. (i) If the type constructors are different the only generalization possible is a type variable c. (ii) Definition 5 (LessGen type class).

5.3 Pointcut Safety

• The authors now establish the safety of pointcuts with relation to join points.
• (On both pcCall and pcType this type comparison is performed by compareType on the type representations of its arguments.).
• Such a pointcut only matches a join point with function g whose type is less general than the matched type.
• The matched type of the com- bined pointcut is the principal unifier of the matched types of the arguments—which represents the intersection of the two sets of join points.

5.5 Safe Aspects

• The authors now show that if an aspect is well-typed, then the advised type of the advice is more general than the type of join points matched by the corresponding pointcut: Theorem 1 (Safe Aspects).
• Therefore (unsafeCoerce adv) corresponds exactly to σadv, and is safe. ⊓⊔.

6 Open and Protected Modules, with Effects

• This section illustrates how the authors can exploit the monadic embedding of aspects to encode Open Modules [2] extended with effects.
• Additionally the authors present the notion of protected pointcuts, which are pointcuts whose type places restrictions on admissible advice.
• The authors illustrate the use of protected pointcuts to enforce control flow properties of external advice, reusing the approach of EffectiveAdvice [28].

6.1 A Simple Example

• The authors first describe a simple example that serves as the starting point.
• Figure 2 describes a Fibonacci module, following the canonical example of Open Modules.
• Note that pcFib uses the user-defined pointcut pcArgGT (defined in Sect. 4.1) to check that the call to fibBase is done with an argument greater than 2.
• The fib function is exported, together with the pcFib pointcut, which can be used by an external module to advise applications of the internal fibBase function.

6.2 Protected Pointcuts

• In order to extend Open Modules with effect-related enforcement, the authors introduce the notion of protected pointcuts, which are pointcuts enriched with restrictions on the effects that associated advice can exhibit.
• If the advice does not respect the (type) restrictions expressed by the combinator, the aspect creation expression simply does not typecheck and hence the aspect cannot be built.
• The key point here is that when building an aspect using a protected pointcut, the combinator comb is applied to the advice adv .
• The authors now show how to exploit this extension of Open Modules to restrict control flow properties, using the proper type combinators.
• The next section describes how to control computational effects.

6.3 Enforcing Control Flow Properties

• Rinard et al. present a classification of advice in four categories depending on how they affect the control flow of programs [34]: – Combination:.
• The advice calls proceed at most once, and does not modify the argu- ments to or the return value of proceed .
• These combinators fit the general Combinator type the authors described in Sect. 6.2, and can therefore be embedded in protected pointcuts.
• Hence, only advice that can be statically typed as narrowing advice can be bound to that pointcut.
• Finally, note that this approach is not limited to the four categories of Rinard et al.; custom kinds of advice can be defined in a similar way.

7 Controlling Effect Interference

• The monadic embedding of aspects also enables reasoning about computational effects.
• The authors are particularly interested in reasoning about effect interference between components of a system: aspects, base programs, and combinations thereof.
• To do this, in Section 7.1 the authors first show how to adapt the non-interference types defined in EffectiveAdvice [28], which distinguish between aspect and base computation.
• Then, because components must work uniformly over the restricted section of the stack, they can only utilize effects available in the non-restricted section.
• In Section 7.2 the authors show how a refinement of the technique can be used to address this situation, but that unfortunately is impractical because it requires explicit liftings and strongly couples components to particular shapes of the monad stack—hampering modularity and reusability.

7.1 Distinguishing Aspect and Base Computation

• To illustrate the usefulness of distinguishing between aspect and base computation, consider a Fibonacci module where the internal calls throw an exception when given a negative integer as argument.
• In that situation, it is interesting to ensure that the external advice bound to the exposed pointcut cannot throw or catch those exceptions.
• Observe that NIAT splits the monad stack into an upper part t , with the effects available to aspects; and a lower part m , with the effects available to base computation.
• The results of Sect. 5 can straightforwardly be rephrased with these new definitions.
• 29 Reasoning About Pointcut Interference Indeed, in the monadic embedding of aspects, the authors allow for effectful pointcuts.

7.2 Interference Between Multiple Aspects

• NIAT only distinguishes between base and aspect computation.
• To illustrate this issue, consider a Fibonacci module program that uses the memo advice to improve the performance, and also uses a checkArg advice that throws an exception when given a negative argument (instead of a base code check as in Fig. 6).
• Using rank-2 types, the following type synonyms guarantee that non-interfering pointcuts and advices access can 30 only access the effect available in the first layer L1, which corresponds to t1; or in the second layer L2, which corresponds to t2.
• Now the authors define the monad stack S that provides the state and error-handling effects.
• In fact, in the presence of implicit lifting the layer from which an effect comes depends on the concrete monad stack used.

7.4 Beyond the Aspect/Base Distinction

• Monad views enable a different approach to enforce non-interference.
• The novelty with respect to using implicit liftings is that the authors can assign to each aspect a virtual view of the monad stack that only contains the effect available to them.
• Consider a monad stack S2, where the state and error layers are tagged: data StateTag data ErrorTag type S2 = AT (T ErrorTag (ET String (T StateTag (ST (Map Int Int) I)).
• In contrast to the previous definition, the authors need to use explicit type annotations because using nominal masks can lead to ambiguity in type inference20.

8 Language Extensions

• The typed monadic embedding of aspects supports modular extensions of the aspect language.
• The simplest extension is to introduce new user-defined pointcuts.
• More interestingly, because the language features a monadic weaver [38], the authors can modularly implement new semantics for aspect scoping and weaving.
• In addition, all language extensions benefit from the type-based reasoning techniques described in this paper—to the best of their knowledge, this is a novel contribution of this work.
• – Privileged aspects that can see hidden join points from a secure computation.

8.1 Cflow Pointcut

• An interesting illustration of extending the language with user-defined pointcuts is the case of control flow checks.
• Function any returns whether any element of jps satisfies a given predicate.
• The authors first define the pcAny pointcut, which matches all functions applications and pushes the corresponding join point into the stack.
• Next, the authors define collectAdv as an advice that performs proceed , pops the stack and returns the result.
• Otherwise, control flow pointcuts from other aspects will have incorrect information to determine whether to execute the advice.

8.2 Secure Weaving

• For security reasons it can be interesting to protect certain join points from being advised.
• To support such a secure weaving, the authors define a new monad transformer AST, which embeds an (existentially quantified) pointcut that specifies the hidden join points, and they modify the weaving process accordingly (not shown here).
• This can be particularly useful when used with the pcCflow pointcut to protect the computation that occurs in the control flow of critical function applications.

8.3 Privileged Aspects

• Hiding some join points to all aspects may be too restrictive.
• Certain “system” aspects like access control should be treated as privileged and view all join points.
• Another example is the aspect in charge of maintaining the join point stack for the sake of control flow reasoning (used by pcCflow ).
• The implementation of a privileged aspects list is a straightforward extension to the secure weaving mechanism described above.

8.4 Execution Levels

• Execution levels avoid unwanted computational interference between aspects, i.e. when an aspect execution produces join points that are visible to others, including itself [41].
• The execution of an aspect (both pointcuts and advices) is therefore not visible to itself and to other aspects deployed at the same level, only to aspects standing one level above.
• The monadic semantics of execution levels are implemented in the ELT monad transformer (Fig. 8).
• When such a function is applied, execution jumps to level l and then goes back to the level prior to the application [41].
• In a setting without execution levels, advising showM with logAdv triggers an infinite loop because logAdv internally performs open applications of showM , which are matched by the same aspect.

8.5 Reasoning about Language Extensions

• The above extensions can be implemented in an dynamically typed language such as LAScheme [41].
• The authors can combine the monadic interpretation of execution levels with the management of effect interference (Sect. 7) in order to reason about level-shifting operations performed by base and aspect computations.
• Then, the authors simply define an advice combinator that forbids access to the ELT layer, which provides the level-shifting operations.
• Suppose that the authors want to define a critical computation, which must only be run with secure weaving for access control.
• The computation must therefore be run within the AST monad transformer with a given pointcut pc_ac (ac stands for access control).

9 Discussion

• The authors now discuss a number of issues related to their approach: how to define a proper notion of function equality, how to deal with overloaded functions, and finally, they analyze the issue of obliviousness.
• 24 We use the WriterT transformer (WT), which is the canonical instance of {WM.the authors.the authors.

9.1 Supporting Equality on Functions

• Pointcuts quantify about join points, and a major element of the join point is the function being applied.
• The pcType designator relies on type comparison, implemented using the PolyTypeable type class in order to obtain representations for polymorphic types.
• Unfortunately, this notion of equality is fragile.
• StableNames equality is safe in the sense that it does not equate two functions that are not the same, but two functions that are equal can be seen as different.
• Indeed, each time a function with constraints is used, a new closure is created by passing the current method dictionary of type class instances.

9.2 Advising Overloaded Functions

• From a programmer’s point of view, it can be interesting to advise an overloaded function (that is, the application of all the possible implementations) with a single aspect.
• This means that all type class constraints must be solved statically at the point an aspect is deployed.
• If the matched and advised types are both bounded polymorphic types, type inference cannot gather enough information to statically solve the constraints.
• To alleviate this problem, the authors developed a macro using TemplateHaskell [36].
• The macro extracts all the constrained variables in the matched type of the pointcut, and generates an annotated deployment for every possible combination of instances that satisfy all constraints.

9.3 Obliviousness

• The embedding of aspects the authors have presented thus far supports quantification through pointcuts, but is not oblivious: open applications are explicit in the code.
• This approach was used in Fig. 2 for the definition of fib.
• Otherwise, it can yield issues in the definition of pointcuts that rely on function identity, because enqueue ′ and enqueue are different functions.
• Also, this approach is not entirely satisfactory with respect to obliviousness because it has to be applied specifically for each function.
• Breaking monadic laws is not prohibited by Haskell, but it is very dangerous and fragile; for instance, some compilers exploit the laws to perform optimizations, so breaking them can yield incorrect optimizations.

9.4 Technical Requirements of our Model

• The current implementation of Effective Aspect uses several extensions of the GHC Haskell compiler (see the details at http://plead.cl/effectiveaspects).
• Nevertheless, the authors believe that the anti-unification algorithm at the type level (Section 4.1) is the essential feature that would be required to make their approach work on other languages.
• A potential line of work is to port Effective Aspects to Scala, which has some likeness to Haskell and also has monads, and investigate what kind of issues arise in the process.

10 Related Work

• The earliest connection between aspects and monads was established by De Meuter in 1997 [26].
• In fact, the join point stack is useful only to express control flow pointcuts.
• The notion of monadic weaving was described by Tabareau [38], where he shows that writing the aspect weaver in a monadic style paves the way for modular language extensions.
• Proving type soundness is therefore very involved [7].
• Aspectual Caml is implemented by modifying the Objective Caml compiler, including modifications to the type inference mechanism.

11 Conclusion

• The authors exploit monads and the Haskell type system to define a typed monadic embedding that supports both modular language extensions and reasoning about effects with pointcut/advice aspects.
• The authors show how to ensure type soundness by design, even in presence of user-extensible pointcut designators, relying on a novel type class for establishing anti-unification.
• The approach can combine Open Modules and EffectiveAdvice, and supports type-based reasoning about modular language extensions.
• This work was supported by the INRIA Associated team REAL.
• The authors thank the anonymous reviewers from the AOSD’13 conference and from this journal, and they also thank Tom Schrijvers for all his useful feedback.

Figures

Fig. 4. Replacement, augmentation and narrowing advice combinators (adapted from [28]).

Fig. 5.Memoization as a narrowing advice (adapted from [28]).

Fig. 6. Fibonacci with error.

Fig. 7. Applying structural masks to the monad stack S1.

Fig. 2. Fibonacci module.

Fig. 8. Execution levels monad transformer and level-shifting operations

Fig. 9. Redefining aspect deployment for execution levels semantics. An aspect is made levelaware by transforming its pointcut and advice.

Fig. 1. The LeastGen ′ type class. An instance holds if c is the least general type of a and b.

Fig. 10. A program that loops unless execution levels are used.

Fig. 3.Memoized Fibonacci module.

Full text

HAL Id: hal-00872782
https://hal.inria.fr/hal-00872782
Submitted on 18 Feb 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Eective Aspects: A Typed Monadic Embedding of
Pointcuts and Advice
Ismael Figueroa, Nicolas Tabareau, Éric Tanter
To cite this version:
Ismael Figueroa, Nicolas Tabareau, Éric Tanter. Eective Aspects: A Typed Monadic Embedding
of Pointcuts and Advice. LNCS Transactions on Aspect-Oriented Software Development, Springer,
2014. �hal-00872782�

Effective Aspects: A Typed Monadic Embedding of
Pointcuts and Advice
Ismael Figueroa
1,2⋆
, Nicolas Tabareau
2
, and Éric Tanter
1⋆⋆
1
PLEIAD Laboratory
University of Chile, Santiago, Chile.
{ifiguero,etanter}@dcc.uchile.cl
http://pleiad.cl
2
ASCOLA group
INRIA – Nantes, France.
nicolas.tabareau@inria.fr
Abstract. Aspect-oriented programming (AOP) aims to enhance modularity and
reusability in software systems by offering an abstraction mechanism to deal with
crosscutting concerns. However, in most general-purpose aspect languages as-
pects have almost unrestricted power, eventually conflicting with these goals. In
this work we present Effective Aspects: a novel approach to embed the point-
cut/advice model of AOP in a statically-typed functional programming language
like Haskell. Our work extends EffectiveAdvice, by Oliveira, Schrijvers and Cook;
which lacks quantification, and explores how to exploit the monadic setting in
the full pointcut/advice model. Type soundness is guaranteed by exploiting the
underlying type system, in particular phantom types and a new anti-unification
type class. Aspects are first-class, can be deployed dynamically, and the pointcut
language is extensible, therefore combining the flexibility of dynamically-typed
aspect languages with the guarantees of a static type system. Monads enables us
to directly reason about computational effects both in aspects and base programs
using traditional monadic techniques. Using this we extend Aldrich’s notion of
Open Modules with effects, and also with protected pointcut interfaces to ex-
ternal advising. These restrictions are enforced statically using the type system.
Also, we adapt the techniques of EffectiveAdvice to reason about and enforce
control flow properties. Moreover, we show how to control effect interference us-
ing the parametricity-based approach of EffectiveAdvice. However this approach
falls short when dealing with interference between multiple aspects. We propose
a different approach using monad views, a recently developed technique for han-
dling the monad stack. Finally, we exploit the properties of our monadic weaver to
enable the modular construction of new semantics for aspect scoping and weav-
ing. These semantics also benefit fully from the monadic reasoning mechanisms
present in the language. This work brings type-based reasoning about effects for
the first time in the pointcut/advice model, in a framework that is both expressive
and extensible; thus allowing development of robust aspect-oriented systems as
well as being a useful research tool for experimenting with new aspect semantics.
Keywords: aspect-oriented programming, monads, pointcut/advice model, type-
based reasoning, modular reasoning
⋆
Funded by a CONICYT-Chile Doctoral Scholarship
⋆⋆
Partially funded by FONDECYT project 1110051.

2
1 Introduction
Aspect-oriented programming languages support the modular definition of crosscutting
concerns through a join point model [19]. In the pointcut/advice mechanism, crosscut-
ting is supported by means of pointcuts, which quantify over join points, in order to
implicitly trigger advice [48]. Such a mechanism is typically integrated in an existing
programming language by modifying the language processor, may it be the compiler
(either directly or through macros), or the virtual machine. In a typed language, intro-
ducing pointcuts and advices also means extending the type system, if type soundness
is to be preserved. For instance, AspectML [7] is based on a specific type system in
order to safely apply advice. AspectJ [18] does not substantially extend the type system
of Java and suffers from soundness issues. StrongAspectJ [8] addresses these issues
with an extended type system. In both cases, proving type soundness is rather involved
because a whole new type system has to be dealt with.
In functional programming, the traditional way to tackle language extensions, mostly
for embedded languages, is to use monads [27]. Early work on AOP suggests a strong
connection to monads. De Meuter proposed to use them to lay down the foundations
of AOP [26], and Wand et al. used monads in their denotational semantics of pointcuts
and advice [48]. Recently, Tabareau proposed a weaving algorithm that supports mo-
nads in the pointcut and advice model, which yields benefits in terms of extensibility
of the aspect weaver [38], although in this work the weaver itself was not monadic but
integrated internally in the system. This connection was exploited in recent preliminary
work by the authors to construct an extensible monadic aspect weaver, in the context
of Typed Racket [14], but the proposed monadic weaver was not fully typed because of
limitations in the type system of Typed Racket.
This work proposes Effective Aspects: a lightweight, full-fledged embedding of as-
pects in Haskell, that is typed and monadic.
3
By lightweight, we mean that aspects
are provided as a small standard Haskell library. The embedding is full-fledged be-
cause it supports dynamic deployment of first-class aspects with an extensible point-
cut language—as is usually found only in dynamically-typed aspect languages like
AspectScheme [11] and AspectScript [45] (Sect. 3).
By typed, we mean that in the embedding, pointcuts, advices, and aspects are all stat-
ically typed (Sect. 4), and pointcut/advice bindings are proven to be safe (Sect. 5). Type
soundness is directly derived by relying on the existing type system of Haskell (type
classes [47], phantom types [21], and some recent extensions of the Glasgow Haskell
Compiler). Specifically, we define a novel type class for anti-unification [32,33], which
is key to define safe aspects.
Finally, because the embedding is monadic, we derive two notable advantages over
ad-hoc approaches to introducing aspects in an existing language. First, we can directly
3
This work is an extension of our paper in the 12th International Conference on Aspect-
Oriented Software Development [39]. We mainly expand on using types to reason about as-
pect interference (Section 7). In addition, we provide a technical background about mona-
dic programming in Haskell (Section 2). The implementation is available, with examples, at
http://pleiad.cl/EffectiveAspects

3
reason about aspects and effects using traditional monadic techniques. In short, we can
generalize the interference combinators of EffectiveAdvice [28] in the context of point-
cuts and advice (Sect. 6). And also we can use non-interference analysis techniques
such as those from EffectiveAdvice, and from other advanced mechanisms, in particular
monad views [35] (Sect. 7). Second, because we embed a monadic weaver, we can mod-
ularly extend the aspect language semantics. We illustrate this with several extensions
and show how type-based reasoning can be applied to language extensions (Sect. 8).
Sect. 9 discusses several issues related to our approach, Sect. 10 reviews related work,
and Sect. 11 concludes.
2 Prelude: Overview of Monadic Programming
To make this work self-contained and to cater to readers not familiar with monads,
we present a brief overview of the key concepts of monadic programming in Haskell
used throughout this paper. More precisely, we introduce the state and error monad
transformers, and the mechanisms of explicit and implicit lifting in the monad stack.
The reader is only expected to know basic Haskell programming and to understand
the concept of type classes. As a good tutorial we suggest [20]. Readers already familiar
with monadic programming can safely skip this section.
2.1 Monads Basics
Monads [27,46] are a mechanism to embed and reason about computational effects
such as state, I/O, or exception-handling in purely functional languages like Haskell.
Monad transformers [22] allow the modular construction of monads that combine sev-
eral effects. A monad transformer is a type constructor used to create a monad stack
where each layer represents an effect. Monadic programming in Haskell is provided
by the Monad Transformers Library (known as MTL), which defines a set of monad
transformers that can be flexibly composed together.
A monad is defined by a type constructor m and functions >>= (called bind) and
return. At the type level a monad is a regular type constructor, although conceptually
we distinguish a value of type a from a computation in monad m of type m a. Monads
provide a uniform interface for computational effects, as specified in the Monad type
class:
class Monad m where
return :: a → m a
(>>=) :: m a → (a → m b) → m b
Here return promotes a value of type a into a computation of type m a, and >>=
is a pipeline operator that takes a computation, extracts its value, and applies an action
to produce a new computation. The precise meanings for return and >>= are specific to
each monad. The computational effect of a monad is “hidden” in the definition of >>=,
which imposes a sequential evaluation where the effect is performed at each step. To
avoid cluttering caused by using >>= Haskell provides the do-notation, which directly

4
translates to chained applications of >>=. The x ← k expression binds identifier x with
the value extracted from performing computation k for the rest of a do block.
4
A monad transformer is defined by a type constructor t and the lift operation, as
specified in the MonadTrans type class:
class MonadTrans t where
lift :: m a → t m a
The purpose of lift is to promote a computation from an inner layer of the monad stack,
of type m a, into a computation in the monad defined by the complete stack, with type
t m a. Each transformer t must declare in an effect-specific way how to make t m an
instance of the Monad class.
2.2 Plain Monadic Programming
To illustrate monadic programming we first describe the use of the state monad trans-
former StateT , denoted as S
T
, whose computational effect is to thread a value with
read-write access.
newtype S
T
s m a = S
T
(s → m (a, s))
evalS
T
:: S
T
s m a → s → m a
A S
T
s m a computation is a function that takes an initial state of type s and re-
turns a computation in the underlying monad m with a pair containing the resulting
value of type a, and a potentially modified state of type s. The eval S
T
function evalu-
ates a State s m a computation using an initial state s and yields only the returning
computation m a. In addition, functions getS
T
and putS
T
allow to retrieve and update
the state inside a computation, respectively
5
.
getS
T
:: Monad m ⇒ S
T
s m s
getS
T
= S
T
$ λs → return (s, s)
putS
T
:: Monad m ⇒ s → S
T
s m ()
putS
T
s
′
= S
T
$ λ
→ return ((), s
′
)
Note that both functions get the current state from some previous operation (>>= or
evalS
T
). The difference is that get S
T
returns this value and keeps the previous state
unchanged, whereas putS
T
replaces the previous state with its argument.
Example Application Consider a mutable queue of integers with operations to enqueue
and dequeue its elements. To implement it we will define a monad stack M
1
, which
threads a list of integers using the S
T
transformer on top of the identity monad I (which
has no computational effect). We also define runM
1
, which initializes the queue with
an empty list, and returns only the resulting value of a computation in M
1
.
4
x ← k performs the effect in k , while let x = k does not.
5
Note the use of $, here and throughout the rest of the paper, to avoid extra parentheses.

Frequently asked questions

Q1. What have the authors contributed in "Effective aspects: a typed monadic embedding of pointcuts and advice" ?

In this work the authors present Effective Aspects: a novel approach to embed the pointcut/advice model of AOP in a statically-typed functional programming language like Haskell. Moreover, the authors show how to control effect interference using the parametricity-based approach of EffectiveAdvice. The authors propose a different approach using monad views, a recently developed technique for handling the monad stack. This work brings type-based reasoning about effects for the first time in the pointcut/advice model, in a framework that is both expressive and extensible ; thus allowing development of robust aspect-oriented systems as well as being a useful research tool for experimenting with new aspect semantics.