Linear Objects

1
Linear Objects
Matthew Kehrt Advised by Jonathan Aldrich
The Problem Linear type systems allow
restrictions to be made on how program values may
be copied. Linearity has been studied
extensively in functional programming languages.
However, linearity has been less well
investigated in other settings. The Ego
language 2 introduced a linear type system for
a simple object-oriented calculus. Egos type
system distinguishes between objects to which
there can be only one reference (linear) and
those to which there can be many references
(nonlinear). However, such linear types are
often confusing to the programmer as they enforce
unintuitive constraints on what code is allowable.
Regions We use a region system to enforce that
temporary references to borrowed objects do not
escape the scope in which they were borrowed.
When we borrow an object, we attach a unique
label, called a region, to the objects type. If
we ever see this region in the type of anything
outside of the expression in which the object is
borrowed, we know we are using an illegal
reference.
Maintaining Linearity To prevent temporary
references to borrowed objects from escaping the
expression in which they were borrowed, we keep
a list of regions currently in scope. In the
previous example, the region under which the
object is borrowed is in scope only in exp2, as
only in this expression are temporary aliases to
the object allowed . When we typecheck a
borrowed object, we make sure the region attached
to its type is in scope. This enforces the
constraint that outside of exp2 there are no
aliases to the borrowed object.
let! Our borrowing mechanism is based on Wadlers
let!3 which does a similar thing in a
functional, rather than object oriented, setting.
Our let! looks like let! (r) x exp1 y
exp2 in exp3 In this code fragment, exp1
is first evaluated to a linear object and its
value is assigned to x. This object is then
borrowed with some region in exp2. exp2 is
evaluated with the variable x in scope but here
x is given a borrowed type with this region
attached. This means that in exp2, multiple
references can be made to this object. Finally,
exp3 is evaluated with both x and y in scope.
Now, the object to which x is bound is no longer
borrowed, so, x is given a linear type so only
one reference to it is allowed. If any borrowed
references to the object are returned out of
exp2, the program will not typecheck, as the
region at which they are borrowed is no longer in
scope. This means only one reference to the
object exists outside of exp2.
Methods and Effects Our objects contain methods
which can mention other objects. We need to be
able to keep methods which mention objects
borrowed at regions no longer in scope from being
called. However, methods may mention objects
borrowed at regions in their bodies without
returning them, and so these regions will not be
part of the methods type. To solve this
problem, we annotate the type of the method with
an effect list, or a list of all the regions used
in the method, so we can tell what regions any
method uses. This way, we can decide whether we
can safely call a method from its type.
Conclusion We have put together a system that
eases the linearity constraint and thus makes Ego
more intuitive and expressive. From this we have
gained a better understanding of the uses of
linearity in object-oriented languages.
The Solution To make programming with linear
objects easier, we introduce a linguistic
construct to ease the linearity constraint in
certain expressions. We do this by allowing a
reference to a linear objects to be borrowed. A
borrowed object can have multiple temporary
references to it. To maintain linearity, we
enforce that none of these temporary references
leave the expression in which the object is
borrowed.

• References
• 1 D. Ungar, R. B. Smith. Self The power of
  simplicity. Proc. Object-Oriented Programming
  Systems, Languages and Applications, 1987.
• 2 Andi Bejleri, Jonathan Aldrich, and Kevin
  Bierhoff. Ego Controlling the Power of
  Simplicity. In Proceedings of the Workshop on
  Foundations of Object Oriented Languages
  (FOOL/WOOD 06), January 2006.
• 3 P. Wadler. Linear types can change the
  world! In M. Broy and C. Jones, editors,
  Programming Concepts and Methods, North Holland,
  1990