A Simple, Symmetric, Subjective Foundation for

Object-, Aspect- and Context-Oriented Programming

Harold Ossher David Ungar Doug Kimelman
IBM Research
Yorktown Heights, NY, USA
{ossher,davidungar,dnk}@[Link]

Abstract In place of an object that constitutes identity as well as a

set of slots, Korz has a coordinate that is solely a value that
Korz is a new computational model that combines implicit constitutes an identity; and instead of being contained by a
arguments (constituting context) with multiple dispatch, in single object, a slot pertains to a number of coordinates, as
a slot-based model. Slots from a multidimensional space are indicated by part of its slot guard (the slot guard also in-
drawn together into “objects” subjectively, in different ways cludes a selector and a list of explicit positional parame-
in different contexts. The combination of these few con- ters).
cepts powerfully supports evolution and contextual varia- In the example shown in Figures 1 through 3, examples
tion along multiple dimensions. Korz holds promise as a of coordinates include: that referred to by the literal 20.0,
foundation for future languages that deeply integrate object- the contents of the constant slots true and pointParent, and
oriented, aspect-oriented and context-oriented capabilities. the contents of the variable slot point1. In Figure 2, an
Nonetheless, a number of issues remain to be resolved. example of a slot guard is: { rcvr ≤ screenParent, grayScale
≤ true } drawPixel(x, y, c) , which indicates that the method
1. Introduction being defined is contained in a slot with selector drawPixel,
has explicit positional parameters x, y, and c, and pertains
Korz [Unga14] introduces a new computational model that to coordinate screenParent (which we say is “in the role of”
combines implicit arguments, which serve as context, and rcvr, or “along the dimension” rcvr) and coordinate true
multiple dispatch, designed to address multidimensional (along the grayScale dimension); that is, the slot is con-
contextual variation. In addition, rather than a fixed organi- strained to only be accessible (eligible for selection by the
zation of method and data slots into objects, a Korz pro- dispatch algorithm) from contexts in which the coordinate
gram fundamentally consists of a multidimensional space of in the rcvr dimension is screenParent, or a descendant
slots, and slots can be drawn together into “objects” subjec- thereof, and the coordinate in the grayScale dimension is
tively, in different ways in different contexts. There is no true (any additional dimensions of the context are irrelevant
dominant decomposition, and no dimension holds sway to the accessibility of this slot).
over any other. At each computation step, multiple dispatch In Korz, a message send occurs in a context consisting of
involving both implicit arguments (context) and explicit a number of coordinates, each in a particular role (or “along
arguments is used to find the appropriate slot to evaluate. a dimension”). The context, selector, and explicit positional
Though these base concepts individually have been arguments of the message send determine the slot to be
known and used for many years, this particular combination evaluated. In Figure 1, { rcvr: point1 }.display is an exam-
is novel and seems especially powerful: early experience ple of a message send (which has no explicit arguments).
shows that it enables the writing of software that supports The context for the message send will include the coordi-
contextual variation along multiple dimensions, and grace- nate point1 in the rcvr dimension, and depending on the
ful evolution of that software to support new, unexpected chain of sends leading up to this send, the context might
dimensions of variability, without the need for additional also implicitly include a coordinate in the device dimen-
mechanism such as layers [Hirs08] or aspects [Kicz97]. sion: stdscreen for example. In this case, syntactic sugar can
The goal of this paper is to provoke consideration and reduce the code for this message send to [Link]. A
discussion of the position that the Korz model is a good message send can add bindings to the context that is being
foundation for future work on languages that deeply inte- implicitly passed along the call chain, as in { rcvr: f1, de-
grate object-, aspect-[Elra01] and context-oriented [Hirs08] vice: s, location: australia }.display in Figure 3, which adds
capabilities. The next section briefly outlines the Korz three bindings to the context before finding and evaluating
model, and is followed by discussion of some of the most a display slot; and a message send can remove bindings
challenging issues that remain outstanding. More details of from the context, as in
Korz, and analysis of related work, are in [Unga14]. { -location }.drawPixel(x, -y, c) in Figure 3, which removes
any binding of the location dimension to a coordinate.
2. Overview of Korz Concepts A slot whose guard has no constraints on context, as in {}
pointParent in Figure 1, is globally accessible; i.e., the
This section introduces basic Korz concepts and terminol- pointParent slot is not constrained at all with respect to the
ogy using a simple point drawing example shown in Fig- contexts from which it is accessible, so it is accessible to
ures 1 through 3.
 def {} pointParent = newCoord; def {} figureParent = newCoord
def {} point = newCoord extending pointParent; def {} figure = newCoord extending figureParent;
var {rcvr ≤ point} x;
var {rcvr ≤ point} y; var {rcvr ≤ figure} point1;
var {rcvr ≤ point} color; var {rcvr ≤ figure} point2;
var {rcvr ≤ figure} point3;
method {} makeAPoint(x, y, c) {
var x, y, c, p; method {rcvr ≤ figureParent} display {
p = [Link]; [Link]; [Link]; [Link]
p.x = x; p.y = y; [Link] = c; }
return p; method { rcvr ≤ screenParent, grayScale ≤ true }
} drawPixel(x, y, c) {
method { {grayScale: false}
rcvr ≤ pointParent, .drawPixel(x, y, [Link])
device //dimension required but can be anything }
} ...
display { { rcvr: f1, device: s, grayScale: true }.display
[Link](x, y, color)
}; ...

Figure 2. Drawing figures in grayscale.

def {} screenParent = newCoord;
def {} screen = newCoord extending screenParent;
def {} locationParent = newCoord;
method {rcvr ≤ screenParent} drawPixel(x, y, color) { def {} location = newCoord extending locationParent;
// draw the pixel in the color def {} southernHemi = newCoord extending location;
} def {} australia = newCoord extending southernHemi;
def {} antarctica = newCoord extending southernHemi;
method {} main() { method { rcvr ≤ screenParent, location ≤ southernHemi
}
var point1 = makeAPoint( 20.0, 30.0, blue );
drawPixel(x, y, c) {
[Link] { -location }.drawPixel(x, -y, c)
// Equivalent to: { rcvr: point1 }.display }
// Context from environment might yield: ...
// { rcvr: point1, device: stdscreen }.display { rcvr: f1, device: s, location: australia }.display
} ...
main();
Figure 3. Drawing figures inverted.
Figure 1. Drawing points on a screen.
Please see [Unga14] for a more detailed walk through of
messages sent from any context. Further, note that if a di- the example code, including the steps by which it evolved,
mension is mentioned in a guard, but is not constrained to as well as a Korz language definition.
any particular coordinate, as for the device dimension in the
guard for the display method in Figure 1, then that dimen- 3. Discussion: Power and Challenges
sion must be present in the context for that slot to be acces-
sible, but any coordinate binding is acceptable. As well, in Multi-dimensional, symmetric models are powerful, but
the body of a method, the coordinate to which a dimension pose some interesting challenges. Many are due to the prin-
is bound may be referred to using the dimension name, as in ciple that dimensions be treated equally: none should be
[Link](x, y, color) in Figure 1. dominant or special, and they should be unordered. The
The code in the figures is structured using a pattern pio- following subsections suggest how the power of the funda-
neered in Self [US87], in which prototype objects define mental approach might be applied to dealing with some of
data slots, and new objects are created by copying proto- the most vexing of these challenges. We feel that these pos-
types, which gives them their own data slots. Method slots sibilities constitute intriguing directions for future research.
are defined in the parent of the prototype, which also be- Dimensions for Interpreter Control
comes the parent of the new objects when the prototype is
copied. The methods are thus inherited by all the copies. A number of the challenges highlighted below can be ad-
dressed by providing some direction to the interpreter. One
approach we have begun to explore for providing such di- This is clumsy, and it gets much worse in the case of cas-
rection is interpreter-control dimensions that affect the caded expressions. The syntactic sugaring allows one to
functioning of the interpreter. An example would be a di- write p.x = x and so on instead, which is much clearer, and
mension that controls the handling of failure: depending on does exactly what an object-oriented programmer would
the value in that dimension, a lookup failure could result in expect. This sugaring, of course, relies on its being clear
different actions, such as bringing up a debugger, logging what dimension is involved. In our current implementation,
the error and terminating the program, or executing context- that dimension is always assumed to be rcvr, and this is the
specific code provided by the developer. Thus, the power of one respect in which rcvr is treated specially. We have be-
being able to introduce new dimensions for new purposes is gun considering a construct that would allow the program-
used below to facilitate graceful language evolution, not mer to specify the dimension to use, which would allow
only program evolution. makeAPoint to be written something like:
with implied dimension = graphic {
The ‘rcvr’ dimension
method {} makeAPoint(x, y, c) {
The dimension rcvr in the example is analogous to the ‘re- var x, y, c, p;
ceiver’ or ‘this’ object of object-oriented languages, and is p = {rcvr: point}.copy;
thus familiar to programmers. It is at odds with two Korz p.x = x; p.y = y; [Link] = c;
principles, however: that a single receiver is replaced by a return p;
multidimensional context, and that all dimensions are }
treated equally. }
It might seem better in the example to have chosen some Now, unfortunately, the copy message can no longer be
other dimension name, perhaps graphic to indicate that it sugared, because it uses a different dimension (whether rcvr
deals with a graphic object. Then the x slot, for example, or something else), but, on balance, this might be a better
would have been defined as var {graphic ≤ point} x. There way to write this particular method. We are also interested
are two problems, however: The first has to do with meth- in IDE support that allows the same code to be viewed in
ods like copy, built-in or library methods that apply broadly. different ways, including with different choices of implied
Such a method must use some dimension for the implicit dimension and consequent sugaring.
parameter it operates on (such a parameter would be the
receiver in object-oriented languages), and since the possi- Lookup Specificity
bilities for such a parameter are so broad and generic, a
domain-specific dimension name like graphic would not As discussed in [Unga14], a situation sometimes arises
suit. We could use a dimension name such as object, entity, where a message matches two slots, one of which has more
thing or the like, but wanted to avoid confusion between dimensions in its slot guard but less-specific coordinates in
coordinates and objects, and also avoid the implication that some of the dimensions that the guards have in common.
objects occur in only one particular dimension. Another We opted to define the slot guard with more dimensions as
possibility might be id or identity, but all coordinates in all being more specific, irrespective of the coordinates in the
dimensions are identities. So we chose rcvr, to be sugges- common dimensions. This decision supports the important
tive of the object-oriented receiver. evolution scenario of adding new dimensions to an existing
One possible solution would be to define methods like system. However, it can be problematic in the case of evo-
copy as global methods that take an explicit parameter: lution involving specialization. An interpreter-control di-
Instead of method { rcvr } copy() { ... } define method {} mension could allow for context-sensitive determination of
copy(x) { ... } . This approach breaks down, however, for specificity, but might reduce code comprehensibility.
methods associated with abstractions like collections, where Super
the use of explicit parameters becomes clumsy and counter In any specificity-based dispatch approach, it is important
to the expectations of object-oriented programmers. In such for a method to be able to trigger invocation of the next-
cases we could possibly use other appropriate dimensions, most-specific method (e.g. via super or call-next-method).
like collection, rather than rcvr. This is a known difficult problem in multiple-dispatch lan-
That leads to the second problem: the need to switch guages, because there is often not a natural, unique next-
between dimensions, and its impact on syntactic sugaring. most-specific method. Rules have to be employed, such as
Suppose we had used the graphic dimension as suggested linearization in CLOS [Gabr91] and all-parents-equal in
earlier. The makeAPoint method would now have to be Self, or the programmer can be explicit, as in C++ and Self.
written: The same issues arise in Korz. They are particularly chal-
method {} makeAPoint(x, y, c) { lenging due to our desire to preserve symmetry and hence
var x, y, c, p; avoid any sort of built in linearization or dimension order-
p = [Link]; ing. An interpreter-control dimension could be applied, al-
{graphic: p}.x = x; {graphic: p}.y = y; lowing the context to specify the order in which dimensions
{graphic: p }.color = c; should be relaxed, to provide context-specific code to be
return p; executed, or to effect some other disambiguation scheme.
} As in the case of lookup specificity, this degree of dy-
namicity could reduce code comprehensibility.
Modularity and AOSD guards rather than being separate elements of slots. For
example, a slot defined in Korz as
Dimensions provide a flexible and powerful modularization method {rcvr ≤ pointParent, device} display {...}
mechanism, that can be used for program organization and would instead be written as
presentation and also has presence at runtime, which is im- method {rcvr ≤ pointParent, device, selector ≤ display} {...}
portant in dynamic languages. A module can be represented This would allow a slot that is to match all messages with
by a specific dimension, or a coordinate within a specific selector display to be written as
dimension. In the first case, the slots to be encapsulated method {selector ≤ display} {...}
must mention that dimension in their guards. In the second Also, with selectors as coordinates, it would be possible to
case, the guards must constrain the dimension to the appro- define parentage, supporting inheritance. This could be
priate coordinate. If either of these approaches is followed, done explicitly, as with other kinds of coordinates, or possi-
slots will be modularized and be inaccessible from other bly using pattern matching, where a pattern is considered an
modules unless the context is explicitly set up to have the ancestor of every selector that it matches. For example, a
appropriate dimension bindings. slot that matches all setters using the standard naming con-
This means that the core mechanism of Korz addresses vention could be written as
many of the evolution scenarios that were the driving force method {selector ≤ set*} {...}
of the aspect-oriented software development (AOSD) The two extensions above have yet to be defined fully
community [Elra01], without the need for additional con- and implemented, but we believe that, rather than being
cepts such as aspects, subjects or layers. Obliviousness is special-purpose mechanisms, they would enhance the Korz
supported because slots can be added as described above model in an elegant and consistent manner. Korz should
without pre-existing slots needing any knowledge of them. then be a suitable foundation for languages that deeply in-
There are, however, two limitations with respect to AOSD tegrate the object-, aspect- and context-oriented paradigms
The first limitation has to do with method combination. (and possibly feature-oriented also; this needs exploration).
When adding functionality to a system, it is often necessary An even more tantalizing – and more speculative – ex-
to add behavior to an existing method (in addition to adding tension is to devise a suitable way to shift perspective so
or replacing methods). This addition is done by such that the slot’s contents becomes one more component of its
mechanisms as advice weaving in AOP [Kicz97] or compo- guard, rather than a separate contents component. Then the
sition in SOP [HO93] and MDSOC [Tarr99], which effec- guard becomes the entire slot, possibly leading to a unifica-
tively allow multiple methods to be executed in response to tion of the object and relational models.
a single message, suitably orchestrated. Korz, on the other
hand, always selects a single, most-specific method to exe- We look forward to in-depth exploration of these and other
cute, and fails if there isn’t one. An interpreter-control di- issues relating to symmetric multidimensional models at the
mension could support other, context-specific options, such workshop, and to input from colleagues with deep insight
as Ensembles [UA10], which run every matching slot for from a number of different perspectives.
this message, or execution of some context-specific “meta-
code” that coordinates execution of the matching slots. In
addition, and possibly in conjunction, the “super” mecha-
References
nism described above can be used to achieve the effect of [Elra01] Elrad, T. et al. (eds.), 2001. Special section on
around advice. aspect-oriented programming. CACM. 44, 10.
The second limitation of Korz relative to AOSD is that
[Gabr91] Gabriel, R. et al. 1991. CLOS: Integrating object-
its support for pointcuts (specifying in one place code that
oriented and functional programming. CACM, 34, 9.
is to be executed at multiple sites, or join points) is limited
to what can be done with inheritance. Multidimensional [Hirs08] Hirschfeld, R. et al. 2008. Context-oriented Pro-
inheritance with dynamic parents is powerful. If an exten- gramming. JOT. 7, 3.
sion provides additional methods for some existing situa- [HO93] Harrison, W. and Ossher, H. 1993. Subject-
tion guarded by coordinates in one or more new dimen- Oriented Programming: A Critique of Pure Objects.
sions, then, provided those dimensions are bound to suitable OOPSLA’93.
coordinates in the context, the new methods will match the [Kicz97] Kiczales, G. et al. 1997. Aspect-Oriented Pro-
original message, and hence be candidates for combination gramming. ECOOP’97.
as determined by the interpreter-control dimension above.
However, the case that is not covered by this is that of [Tarr99] Tarr, P. et al. 1999. N degrees of separation: multi-
selector-based matching: for example, adding behavior to dimensional separation of concerns. ICSE’99.
all methods with a particular selector, irrespective of the [UA10] Ungar, D. and Adams, S. 2010. Harnessing Emer-
other elements of their guards. This case can be handled by gence for Manycore Programming: Early Experience
the kind of extension to Korz that is discussed next. Integrating Ensembles, Adverbs, and Object-based In-
heritance. OOPSLA’10 Short Paper.
Can We Go Even Further With Symmetry? [Unga14] Ungar, D. et al. 2014. Korz: Simple, Symmetric,
Subjective, Context-Oriented Programming. Onward’14.
We believe that we can make the Korz model conceptu-
ally more elegant by treating selectors as coordinates in a [US87] Ungar, D. and Smith, R. B. 1987. Self: The Power
“selector” dimension. Selectors would then move into slot of Simplicity. OOPSLA’87.