!!! Superposition

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

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

! 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

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.