Abstract not found

We study the incorporation of generic types in aspect languages. Since advice acts like method update, such a study has to accommodate the subtleties of the interaction of classes, polymorphism and aspects. Indeed, simple examples demonstrate that current aspect compiling techniques do not avoid runtime type errors. We explore type systems with polymorphism for two models of parametric polymorphism: the type erasure semantics of Generic Java, and the type carrying semantics of designs such as generic C#. Our main contribution is the design and exploration of a source-level type system for a parametric OO language with aspects. We prove progress and preservation properties. We believe our work is the first source-level typing scheme for an aspect-based extension of a parametric object-oriented language. Key words: Aspect-oriented programming, Typing, Generic types. 1

Advice is a mechanism, widely used in aspect-oriented languages, that allows one program component to augment or modify the behavior of other components. When advice and other components are composed together they become tightly coupled, sharing both control and data flows. However this creates important problems: modular reasoning about a component becomes very difficult; and two tightly coupled components may interfere with each other’s control and data flows. This paper presents EffectiveAdvice, a disciplined model of advice, inspired by Aldrich’s Open Modules, that has full support for effects. With EffectiveAdvice, equivalence of advice, as well as base components, can be checked by equational reasoning. The paper describes EffectiveAdvice as a Haskell library in which advice is modeled by mixin inheritance and effects are modeled by monads. Interference patterns previously identified in the literature are expressed as combinators. Parametricity, together with the combinators, is used to prove two harmless advice theorems. The result is an effective semantic model of advice that supports effects, and allows these effects to be separated with strong non-interference guarantees, or merged as needed.

Aspect Oriented Programming can arbitrarily distort the semantics of programs. In particular, weaving can invalidate crucial safety and liveness properties of the base program. In this article, we identify categories of aspects that preserve some classes of properties. It is then sufficient to check that an aspect belongs to a specific category to know which properties will remain satisfied by woven programs. Our categories of aspects, inspired by Katz’s, comprise observers, aborters and confiners. Observers introduce new instructions and a new local state but they do not modify the base program’s state and control-flow. Aborters are observers which may also abort executions. Confiners only ensure that executions remain in the reachable states of the base program. These categories (along with three other) are defined precisely based on a language independent abstract semantics framework. The classes of properties are defined as subsets of LTL for deterministic programs and CTL * for non-deterministic ones. We can formally prove that, for any program, the weaving of any aspect in a category preserves any property in the related class. We give examples

Abstract. The separation of concerns is a fundamental principle in software engineering. Crosscutting concerns are concerns that do not align with hierarchical and block decomposition supported by mainstream programming languages. In the past, crosscutting concerns have been studied mainly in the context of object orientation. Feature orientation is a novel programming paradigm that supports the (de)composition of crosscutting concerns in a system with a hierarchical block structure. In two case studies we explore the problem of crosscutting concerns in functional programming and propose two solutions based on feature orientation. 1

Term rewriting is in the intersection of our interests and physical distance has never been large. Nonetheless we seem to be living at opposite ends of the term rewriting galaxy. Here is a story from the other side of that galaxy. Abstract. We explore the connection between term rewriting systems (TRS) and aspect-oriented programming (AOP). Term rewriting is a paradigm that is used in fields such as program transformation and theorem proving. AOP is a method for decomposing software, complementary to the usual separation into programs, classes, functions, etc. An aspect represents code that is scattered across the components of an otherwise orderly decomposed system. Using AOP, such code can be modularized into aspects and then automatically weaved into a system. Aspect weavers are available for only a handful of languages. Term rewriting can offer a method for the rapid prototyping of weavers for more languages. We explore this claim by presenting a simple weaver implemented as a TRS. We also observe that TRS can benefit from AOP. For example, their flexibility can be enhanced by factoring out hardwired code for tracing and logging rewrite rules. We explore methods for enhancing TRS with aspects and present one application: automatically connecting an interactive debugger to a language specification. 1

Abstract. Statically typed AOP languages restrict application of around advice only to the join points that have conforming types. Though the restriction guarantees type safety, it can prohibit application of advice that is useful, yet does not cause runtime type errors. To this problem, we present a novel weaving mechanism, called the type relaxed weaving, that allows such advice applications while preserving type safety. This paper discusses language design issues to support the type relaxed weaving in AOP languages. 1 Advice Mechanism in AspectJ The advice mechanism in aspect-oriented programming (AOP) languages is a powerful means of modifying behavior of a program without changing the program text. AspectJ[6] is one of the most widely-used AOP languages that support advice mechanism. It is, in conjunction with the mechanism called the inter-type declarations, shown to be useful for modularizing crosscutting concerns, such as logging, profiling, persistency and enforcement[1, 3, 10, 12]. One of the unique features of the advice mechanism is the around advice, which can change parameter and return values of join points (i.e., specific kinds of events during program execution including method calls, constructor calls and field accesses). With around advice, it becomes possible to define such aspects that directly affect values passed in the program, including caching results, pooling resources and encrypting parameters. In object-oriented programming, around advice is also useful to modify functions of a system that are represented as objects by inserting proxies and wrappers, and by replacing with objects that offer different functionality. 1.1 Example of Around Advice We first show a typical usage of around advice by taking a code fragment (Fig. 1) in a graphical drawing application 1 that stores graphical data into a file, which

Statically typed aspect-oriented programming languages restrict application of around advice only to the join points that have conforming types. Though the restriction guarantees type safety, it can prohibit application of advice that is useful, yet does not cause runtime type errors. To this problem, we present a novel weaving mechanism, called the type relaxed weaving, that allows such advice applications while preserving type safety. We formalized the mechanism, and implemented as an AspectJ compatible compiler, called RelaxAJ.

What’s this talk about? Aspect-oriented programming (AOP) is an emerging paradigm to aid the user in the modularization of cross-cutting concerns. Type classes are an established concept to support ad-hoc polymorphism. Both concepts have been so far studied in isolation. We will see that type classes support AOP to some extent. Main observation: type classes ≈ C++ templates ≈ Java interfaces

Aspect-Oriented Programming (AOP) aims at modularising crosscutting concerns that show up in software. The success of AOP has been almost viral and nearly all areas in Software Engineering and Programming Languages have become “infected ” by the AOP bug in one way or another. Interestingly the functional programming community (and, in particular, the pure functional programming community) seems to be resistant to the pandemic. The goal of this paper is to debate the possible causes of the functional programming community’s resistance and to raise awareness and interest by showcasing the benefits that could be gained from having a functional AOP language. At the same time, we identify the main challenges and explore the possible design-space. Categories and Subject Descriptors D.3.2 [Programming Languages]: Language Classifications—Applicative (functional) languages,