The essential idea of superposition is very similar to that of aspects or features. The programmer specifies an event which will trigger a superposed expression.

How does superposition interact with modules?#

Modules and superposition both solve issues of code reuse and program composition. It appears that certain approaches to superposition and modules complement each other nicely. This is already known from other languages which combine object-oriented programming (an approach to modules) with features or aspects (approaches to superposition).

On the other hand, considering superposition and modules separately ensures we do not conflate the two and end up limiting our view of superposition to work with modules, or visa versa. We are not aware of any research involving superposition in a functional language (without modules), so this may also be a more fertile research area.

How are events identified?#

When declaring a superposition, the programmer must specify which events trigger the superposition. In AOP literature such specifications are called pointcuts.

We have decided currently to consider as events calls and returns of named expressions (i.e. definitions). So to identify an event, one need only identify the definition and specify whether to superpose on the call ("before"), return ("after"), or both ("around"). In the presence of modules, module exports provide names for definitions which can participate in superposition. Otherwise, lexical variables (bound to definitions) can serve the same purpose.

How is a superposition related to an event?#

If E is a definition body and F is to be superposed on it, the result of the superposition may be defined with any of the Orc combinators:

  • F | E
  • F >> E, E >> F
  • E << F, F << E
  • E ; F, F ; E

The original concept of superposition only allowed "F | E", i.e. F and E do not communicate directly. However many pratical examples (such as superposing locking on a data structure) require "F >> E" and "E >> F", and there is no obvious reason to disallow the other Orc combinators.

How are superpositions related to each other?#

If a superposition is a function on expressions, then superpositions can be composed via function composition. The order in which superpositions are composed should be determined by a precedence rule, probably related to scope (i.e. outermost first). We discussed the possibility of leaving precedence unspecified, but this seems problematic.

Scope of Superposition#

It does not make sense to define a superposition over a lexical scope, because such a superposition could be trivially inlined by the programmer. Therefore superposition must have a non-lexical static scope, or some form of dynamic scope.

Static Superposition#

Under this regime, a superposition is declared on a name which is statically resolvable to a definition, and it affects all uses of that definition. This is analogous to FOP, or AOP's so-called "static pointcuts". Such superpositions are straightforward to implement via a compiler transformation, provided the superposed expression does not refer to free variables not available to the definition.

This form of superposition primarily provides a software-engineering benefit; definitions can be broken into pieces and organized in a way that is easily understood by programmers (for example, according to features). However I suspect this is not powerful enough for the use cases we have been looking at.

Module Extension#

One module extends another with superpositions. Calls made via the extended module use the superpositions, while calls to the original module do not. This is essentially identical to object-oriented inheritance. It is necessary to distinguish regular definitions (which are lexically scoped) from module methods (which are open to extension). This issue has been very well studied in object-oriented languages.

It may be important to distinguish module exports for superposition from module exports for instances. This distiction is similar to that between protected and public methods in Java.

Instance Extension#

An instance of a module is extended with superpositions which are active only for that instance. If "Module Extension" is equivalent to class-based inheritance, "Instance Extension" is equivalent to prototype-based inheritance.

Dynamic Scope#

A superposition is defined to hold for the dynamic region of some goal expression to be evaluated. In other words, when a token enters the goal expression, the corresponding superposition becomes active, and remains active for that token and all its children until they leave the goal expression.

This mechanism is both easy to understand and powerful, however it is not obvious how to implement it efficiently.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-1) was last changed on 23-Mar-2009 10:49 by AdrianQuark