Kawa internals: Compiling Scheme to Java

Kawa has a rudimentary hierarchy of collection classes.

class Sequence
{ ...;
  abstract public int length();
  abstract public Object elementAt(int i);
}

A Sequence is the abstract class that includes lists, vectors, and strings.

class FString extends Sequence
{ ...;
  char[] value;
}

Used to implement fixed-length mutable strings (array of Unicode character). This is used to represent Scheme strings.

class FVector extends Sequence
{ ...;
  Object[] value;
}

Used to implement fixed-length mutable general one-dimensional array of Object. This is used to represent Scheme vectors.

public class List extends Sequencw
{ ...;
  protected List () { }
  static public List Empty = new List ();
} 

Used to represent Scheme (linked) lists. The empty list '() is the special static value List.Empty. Non-empty-lists are implemented using Pair objects.

public class Pair extends List
{ ...;
  public Object car;
  public Object cdr;
}

Used for Scheme pairs, i.e. all non-empty lists.

public class PairWithPosition extends Pair
{ ...;
}

Like Pair, but includes the filename and linenumber in the file from which the pair was read.

Future plans include more interesting collection classes, such a sequences implemented as a seekable disk file; lazily evaluated sequences; hash tables; APL-style multi-dimensional arrays; stretchy buffers. (Many of these ideas were implemented in my earlier experimental language Q -- see [Bothner88] and ftp://ftp.cygnus.com/pub/bothner/Q/. I will also integrate the Kawa collections into the new JDK 1.2 collections framework.

class Environment
{ ...;
}

An Environment is a mapping from symbols to bindings. It is used for the bindings of the user top-level. There can be multiple top-level Environments, and an Environment can be defined as an extension of an existing Environment. The latter feature is used to implement the various standard environment arguments that can be passed to eval, as adopted for the latest Scheme standard revision, R5RS. Nested environments were also implemented to support threads, and fluid bindings (even in the presence of threads).

Environments will be integrated into a more general name-table interface, which will also include records and ECMAScript objects.

Symbols represent identifiers, and do not need much functionality. Scheme needs to be able to convert them to and from Scheme strings, and they need to be “interned” (which means that there is a global table to ensure that there is a unique symbol for a given identifier). Symbols are immutable and have no accessible internal structure.

Scheme symbols are reprented using interned Java Strings. Note that the Java String class implements immutable strings, and therefore cannot be used to implement Scheme strings. However, it makes sense to use it to implement symbols, since the way Scheme symbols are used is very similar to how Java Strings are used. The method intern in String provides an interned version of a String, which provides the characters-to-String mapping needed for Scheme strings.

Many operations are overloaded to have different definitions depending on the argument types. The classic examples are the functions of arithmetic such as “+”, which needs to use different algorithms depending on the argument types. If there is a fixed and reasonably small set of number types (as is the case with standard Scheme), then we can just enumerate each possibility. However, the Kawa system is meant to be more extensible and support adding new number types.

The solution is straight-forward in the case of a one-operand function such as “negate”, since we can use method overriding and virtual method calls to dynamically select the correct method. However, it is more difficult in the case of a binary method like “+,” since classic object-oriented languages (including Java) only support dynamic method selection using the type of the first argument (“this”). Common Lisp and some Scheme dialects support dynamic method selection using all the arguments, and in fact the problem of binary arithmetic operations is probably the most obvious example where “multi-dispatch” is useful.

Since Java does not have multi-dispatch, we have to solve the problem in other ways. Smalltalk has the same problems, and solved it using “coercive generality”: Each number class has a generality number, and operands of lower generality are converted to the class with the higher generality. This is inefficient because of all the conversions and temporary objects (see [Budd91Arith]), and it is limited to what extent you can add new kinds of number types.

In “double dispatch” [Ingalls86] the expression x-y is implemented as x.sub(y). Assuming the (run-time) class of x is Tx and that of y is Ty, this causes the sub method defined in Tx to be invoked, which just does y.subTx(x). That invokes the subTx method defined in Ty which can without further testing do the subtraction for types Tx and Ty.

The problem with this approach is that it is difficult to add a new Tz class, since you have to also add subTz methods in all the existing number classes, not to mention addTz and all the other operations.

In Kawa, x-y is also implemented by x.sub(y). The sub method of Tx checks if Ty is one of the types it knows how to handle. If so, it does the subtraction and returns the result itself. Otherwise, Tx.sub does y.subReversed(x). This invokes Ty.subReversed (or subReversed as defined in a super-class of Ty). Now Ty (or one of its super-classes) gets a chance to see if it knows how to subtract itself from a Tx object.

The advantage of this scheme is flexibility. The knowledge of how to handle a binary operation for types Tx and Ty can be in either of Tx or Ty or either of their super-classes. This makes is easier to add new classes without having to modify existing ones.

The DSSSL language [DSSSL] is a dialect of Scheme used to process SGML documents. DSSSL has “quantities” in addition to real and integer numbers. Since DSSSL is used to format documents, it provides length values that are a multiple of a meter (e.g. 0.2m), as well as derived units like cm and pt (point). A DSSSL quantity is a product of a dimension-less number with an integral power of a length unit (the meter). A (pure) number is a quantity where the length power is zero.

For Kawa, I wanted to merge the Scheme number types with the DSSSL number types, and also generalize the DSSSL quantities to support other dimensions (such as mass and time) and units (such as kg and seconds). Quantities are implemented by the abstract class Quantity. A quantity is a product of a Unit and a pure number. The number can be an arbitrary complex number.

public class Quantity extends Number
{ ...;
  public Unit unit()
  { return Unit.Empty; }
  public abstract Complex number();
}

public class CQuantity extends Quantity
{ ...;
  Complex num;
  Unit unt;
  public Complex number()
  { return num; }
  public Unit unit()
  { return unt; }
}

A CQuantity is a concrete class that implements general Quantities. But usually we don't need that much generality, and instead use DQuanity.

public class DQuantity extends Quantity
{ ...;
  double factor;
  Unit unt;
  public final Unit unit()
  { return unt; }
  public final Complex number()
  { return new DFloNum(factor); }
}

public class Unit
{ ...;
  String name; // Optional.
  Dimensions dims;
  double factor;
}

A Unit is a product of a floating-point factor and one or more primitive units, combined into a Dimensions object. The Unit may have a name (such as “kg”), which is used for printing, and when parsing literals.

public class BaseUnit extends Unit
{ ...;
  int index;
}

A BaseUnit is a primitive unit that is not defined in terms of any other Unit, for example the meter. Each BaseUnit has a different index, which is used for identification and comparison purposes. Two BaseUnits have the same index if and only if they are the same BaseUnit.

public class Dimensions
{
  BaseUnit[] bases;
  short[] powers;
}

A Dimensions object is a product and/or ratio of BaseUnits. You can think of it as a data structure that maps every BaseUnit to an integer power. The bases array is a list of the BaseUnits that have a non-zero power, in order of the index of the BaseUnit. The powers array gives the power (exponent) of the BaseUnit that has the same index in the bases array.

Two Dimensions objects are equal if they have the same list of bases and powers. Dimensions objects are “interned” (using a global hash table) so that they are equal only if they are the same object. This makes it easy to implement addition and subtraction:

public static DQuantity add
  (DQuantity x, DQuantity y)
{
  if (x.unit().dims != y.unit().dims)
     throw new ArithmeticException
       ("units mis-match");
  double r = y.unit().factor
     / x.unit().factor;
  double s = x.factor + r * y.factor;
  return new DQuantity (s, x.unit());
}

The Unit of the result of an addition or subtraction is the Unit of the first operand. This makes it easy to convert units:

(+ 0cm 2.5m)    ==>    250cm

Because Kawa represents quantities relative to user-specified units, instead of representing them relative to primitive base units, it can display quantities using the user's preferred units, rather than having to use prmitive units. However, this does make multiplication and division a problem The actual calculation (finding the right Dimensions and multiplying the constant factors) is straight-forward. The difficulty is that we have to generate a new compound Unit, and print it out in a reasonable fashion. Exactly how this should best be done is not obvious.

A user-defined Scheme procedure is compiled to a class that is descended from Procedure. For example, a variable-argument procedure is implemented as a sub-class of ProcedureN, with an applyN method comprising the bytecode compiled from the Scheme procedure body. Thus primitive and user-defined procedure have the same calling convention.

Top-level forms (including top-level definitions) are treated as if they were nested inside a dummy procedure. They are compiled as sub-classes of ModuleBody:

class ModuleBody extends Procedure0
{ ...;
  public Object apply0()
  { return run(Environment.current());}
  public abstract Object run
    (Environment env);
}

When a file is loaded, the result is a ModuleBody; invoking run causes the top-level actions to be executed.

Kawa has various hooks for inlining procedures. This can allow substantial speedups, at the cost of some generality and strict standards-compliance, since it prevents re-assigning the inlined procedures. Most of these hooks work by having the compiler notice that a name in function call position is not lexically bound, yet it is declared in the (compile-time) global scope.

The most powerful and low-level mechanism works by having the compiler note that the procedure implements the Inlineable interface. That means it implements the specical compile method, which the compiler calls at code generation time; it can generate whatever bytecode it wants. This is a way for special procedues to generate exotic bytecode instructions. This hook is only available for builtin procedures written in Java.

Another mechanism uses the Java reflective facilities. If the compiler notices that the class of the procedure provides a static method with the right name (apply), and the right number of parameters, then it generates a direct call to that static method. This is not inlining per se, but it does by-pass the (currently significant) overhead of looking up the name in the global symbol-table, casting the value to a procedure, and then making a virtual function call. Also, because the procedure is replaced by a call to a statically known method, that call could actually be inlined by a Java bytecode optimizer. Another advantage of calling a known static method is that the parameter and return types can be more specific than plain Object, or even be unboxed primitive types. This can avoid many type conversions.

The Kawa compiler generates a suitable apply method for all fixed-arity procedures that do not require a closure, so this optimization is applicable to a great many procedures.

Finally, Kawa has preliminary support for true inlining, where a procedure that is only called in one place except for tail-calls, is inlined at the call-site. I plan to add an analysis pass to detect when this optimization is applicable. For now, there is a special case to handle the do special looping form, and these are now always implemented in the natural way (as inlined loops). The “named let” cannot always be implemented as an inlined loop, so implementing that equally efficiently will need the planned analysis phase.

Languages that provide first-class nested functions with lexical scoping have to deal with variables that an inner function “captures” from surrounding lexical scopes. The standard solution uses a “closure” to represent a function together with the environment of captured variables. The original Java language definition did not support nested functions. However, it did have objects and classes, and it turns out the objects and first-class functions are similar in power, since a closure can be represented using an object and vice versa. The “inner classes” added to Java in JDK 1.1 are an object-oriented form of first-class functions. The Java compiler translates the nested classes into plain objects and non-nested classes, very much like Kawa represents nested Scheme functions.

Kawa implements a closure as a Procedure object with a “static link” field that points to the inherited environment. Older versions of Kawa represented the environment as an array. The most recent version uses the Procedure instance itself as the environment. Let us look at how this works, starting with a very simple example:

(define (f1 a)
  (define (f2 b)
    (list a b))
  (cons a f2))

This gets compiled to the bytecode equivalent of:

class F1 extends Procedure1
{
  public Object apply1(Object a)
  { // body of f1
    F2 heapFrame = new F2();
    heapFrame.a = a;
    return Cons.apply2(heapFrame.a,
                      heapFrame);
  }
}

class F2 extends Procedure1
{
  // F2 closureEnv = this;
  Object a;
  public Object apply1(Object b)
  { // body of f2
    return List.apply2(this.a, b);
  }
}

Note that the instance of F2 that represents the f2 procedure contains both the code (the apply1 methods), and the captured instance variable a as a Java field. Note also that the parent function f1 must in general use the same field instance when accessing a, in case one or the other function assigned to a using a set!.

Next, a slightly more complex problem:

(define (f3 a)
  (define (f4 b)
    (cons a b))
  (define (f5 c)
    (cons a c))
  (cons a f5))

In this case all three functions refers to a. However, they must all agree on a single location, in case one of the functions does a set! on the variable. We pick f4 as the home of a (for the simple but arbitrary reason that the compiler sees it first).

class F3 extends Procedure1
{
  public Object apply1(Object a)
  { // body of f3
    F4 heapFrame = new F4();
    heapFrame.a = a;
    return Cons.apply2(heapFrame.a,
                      new F5(heapFrame));
  }
}

class F4 extends Procedure1
{
  // F4 closureEnv = this;
  Object a;
  public Object apply1(Object b)
  { // body of f4
    return Cons.apply2(this.a, b);
  }
}

class F5 extends Procedure1
{
  F4 closureEnv;
  public F5 (F4 closureEnv)
  {
    this.closureEnv = closureEnv;
  }
  public Object apply1(Object c)
  { // body of f5
    return Cons.apply2(closureEnv.a, c);
  }
}

If a variables is captured through multiple levels of nested functions, the generated code need to follow a chain of static links, as shown by the following function.

(define (f6 a)
  (define (f7 b)
    (define (f8 c)
      (define (f9 d)
        (list a b c d))
      (list a b c f9))
    (list a b f8))
  (list a f7))

That gets compiled into bytecodes equivalent to the following.

class F6 extends Procedure1
{
  public Object apply1(Object a)
  { // body of f6
    F7 heapFrame = new F7();
    heapFrame.a = a;
    return List.apply2(heapFrame.a,
                       heapFrame);
  }
}

class F7 extends Procedure1
{
  Object a;
  public Object apply1(Object b)
  { // body of f7
    F8 heapFrame = new F8(this);
    heapFrame.b = b;
    return List.apply3(this.a,
        heapFrame.b, heapFrame);
  }
}

class F8 extends Procedure1
{
  Object b;
  F7 staticLink;
  public F8(F7 staticLink)
  {
    this.staticLink = staticLink;
  }
  public Object apply1(Object c)
  { // body of f8
    F9 heapFrame = new F9(this);
    heapFrame.c = c;
    return List.apply4(staticLink.a,
        this.b, heapFrame.c, heapFrame);
  }
}

class F9 extends Procedure1
{
  Object c;
  F8 staticLink;
  public F9(F8 staticLink)
  {
    this.staticLink = staticLink;
  }
  public Object apply1(Object d)
  { // body of f9
    return List.apply4
      (staticLink.staticLink.a,
        staticLink.b, this.c, d);
  }
}

Handling tail-recursion is another complication. The basic idea is to divide the procedure prologue into the actions before the loop head label, and those after. (Note that allocating a heapFrame has to be done after the head label.) Handling inlining also requires care.

class Syntax
{ ...;
  public abstract Expression rewrite
    (Object obj, Translator tr);
}

The rewrite method in Translator checks for syntactic keywords and macros. If the car of a “call” is a Syntax or if it is a Symbol that is bound to a Syntax, then its rewrite method is called.

As an example, this trivial class implements quote:

class quote extends Syntax
{ ...;
  public Expression rewrite
    (Object obj, Translator tr)
  { // Error-checking is left out.
    return new QuoteExp(((Pair)obj).car);
  }
}

Much more complicated is the Syntax that implements define-syntax.

class define_syntax extends Syntax
{ ...;
  public Expression rewrite
    (Object obj, Translator tr)
  {  enter (new SyntaxRules (...)); }
}

The result is a SyntaxRules object, which contains an encoded representation of the patterns and templates in the syntax-rules. This is in its own right a Syntax object.

class SyntaxRules extends Syntax
{ ...;
  SyntaxRule[] rules;
  public Expression rewrite
    (Object obj, Translator tr)
  {
    Object[] v = new Object[maxVars];
    for (int i = 0;  i < rules.length;)
    {
      SyntaxRule r = rules[i++];
      if (r.match (obj, v))
        return r.execute_template(v, tr);
    }
    return tr.syntaxError
      ("no matching syntax-rule");
  }
}

Contrast evaluating a procedure definition (lambda), which causes a new sub-class of Procedure to be created and compiled, while evaluating a define-syntax only causes a new instance of SyntaxRules to be created.

Most operations in the Java VM leave their result on the VM stack, where they are available for succeeding operations. The obvious and general way to compile an expression is therefore to generate bytecode instructions that leave the result (in the form of a Object reference) on the stack. This handles most cases quite well, but we can do better. We specify a Target parameter when invoking the compile method; the Target specifies where to leave the result.

public abstract class Target
{ ...;
  public abstract void compileFromStack
    (Compilation comp, Type stackType);
  public static final Target Ignore
  = new IgnoreTarget();
}

An Expression's compile method does not have to handle all the kinds of Targets, as long as it can generate code to leave the result on the VM stack, and then invoke compileFromStack, which is responsible for moving the result to the actual target.

The simplest Target is an IgnoreTarget. It is used when the result of an expression will be ignored, but we still need to evaluate it for possible side-effects. The implementation of IgnoreTarget.compileFromStack just emits an instruction to pop a value from the VM stack. Expressions that have no side-effects can check if the target is an IgnoreTarget, and then immediately return. This saves a useless push-pop pair.

The usual Target is an StackTarget. This specifies that an expression should leave the result on the VM stack. Normally, the type of the result is Object, but a StackTarget can specify some other expected type, when that can be determined. The implementation of StackTarget.compileFromStack is also trivial: If the type of the result on the stack is a sub-type of the expected target type, nothing needs to be done; otherwise, it generates code to do the type conversion.

Things get more interesting when we come to ConditionalTarget.

public class ConditionalTarget
    extends Target
{ ...;
  public Label ifTrue, ifFalse;
}

A ConditionalTarget is used when compiling the test expression in a conditional. The expression is evaluated as a boolean value; if the result is true, control transfers to ifTrue; otherwise control transfers to ifFalse. Using ConditionalTarget makes it straight-forward to generate optimal code for nested conditionals, including and and or macros, and (when inlining) functions such as not and eq?.

The ClassType and Method classes are in a separate gnu.bytecode package, which is an intermediate-level interface to code generation and Java .class files. It is essentially independent of Scheme or the rest of Kawa.

class ClassType extends Type
{ ...;
  CpoolEntry[] constant_pool;
  Method methods; // List of methods.
  Field fields; // List of fields.
  public Field addField
    (String name, Type type, int flags)
  { ...Create new field... }
  public method addMethod(String name,...)
  { ...Create new method... }
  public void writeToStream
    (OutputStream stream) { ... }
  public void writeToFile(String filename)
  { ... }
  public byte[] writeToArray()
  { ... }
}

The ClassType class is the main class of the bytecode package. It manages a list Fields, a list of Methods, and the constant pool. There are utility methods for adding new fields, methods, and constant pool entries.

When the ClassType has been fully built, the writeToFile method can be used to write out the contents into a file. The result has the format of a .class file [JavaVmSpec]. Alternatively, the class can be written to an internal byte array (that has the same layout as a .class file) using the writeToArray method. The resulting byte array may be used by a ClassLoader to define a new class for immediate execution. Both of the these methods are implemented on top of the more general writeToStream.

Each method is represented by a Method object.

class Method implements AttrContainer
{ ...;
  Type[] arg_types;
  Type return_type;
  Attribute attributes;
}

An AttrContainer is an object that contains zero or more Attributes. The Java .class file format is quite extensible. Much of the information is stored in named attributes. There are standard attributes, but an application can also define new ones (that are supposed to be ignored by applications that do not understand them). Each class file may have a set of top-level attributes. In addition, each field and method may have attributes. Some standard attributes may have nested sub-attributes.

public abstract class Attribute
{ ...;
  AttrContainer container;
  String name;
}

An Attribute's container specifies who owns the attribute. The attribute also has a name, plus methods to gets its size, write it out, etc.

The most interesting (and large) standard Attribute occurs in a method and has the name "Code". It contains the actual bytecode instructions of a non-native non-abstract method, and we represent it using CodeAttr.

class CodeAttr extends Attribute
{ ...;
  Variable addLocal(Type t, String name)
  { ... }
  public void emitLoad(Variable var)
  { ... }
  public void emitPushInt(int i)
  { ... }
  public void putLineNumber(int lineno)
  { ... }
}

As an example of the level of functionality, emitPushInt compiles code to push an integer i on stack. It selects the right instruction, and if i is too big for one of the instructions that take an inline value, it will create a constant pool entry for i, and push that.

The method addLocal creates a new local variable (and makes sure debugging information is emitted for it), while emitLoad pushes the value of the variable on the stack.

Kawa calls putLineNumber to indicate that the current location corresponds to a given line number. These are emitted in the .class file, and most Java interpreters will use them when printing a stack trace.

We use gnu.bytecode mainly for generating .class files, but it also has classes to read .class files, and also classes to print a ClassType in readable format. The combination makes for a decent Java dis-assembler.

There are other toolkits for creating or analyzing .class files, but gnu.bytecode was written to provide a lot of support for code generation while having little overhead. For example, some assemblers represent each instruction using an Instruction instance, whereas CodeAttr just stores all the instruction in a byte array. Using a linked list of Instructions may be more “object-oriented”, and it does make it easier to do peep-hole optimizations, but the time and space overhead compared to using an array of bytes is huge. (If you do need to do peephole optimizations, then it makes sense to use a doubly-linked list of Instructions, but to use that in conjunction with CodeAttr. You will in any case want a byte-array representation for input and output.)

A Scheme quoted form or self-evaluating form expands to a QuoteExp. Compiling a QuoteExp would seem a trivial exercise, but it is not. There is no way to embed (say) a list literal in Java code. Instead we create a static field in the top-level class for a each (different) QuoteExp in the body we are compiling. The code compiled for a QuoteExp then just needs to load the value from the corresponding static field. The tricky part is making sure that the static field gets initialized when the top-level class is loaded to the value of the literal. This is easy when compiling for immediate execution: after the compiled class has been loaded and initialized, we use reflection to set the field to the literal value. When compiling to a class file, things are harder.

The basic idea is that for:

(define (foo) '(3 . 4))

we compile the equivalent of:

class foo extends Procedure0
{
  Object static lit1
    = Pair.make(IntNum.make(3),
                IntNum.make(4));
  public Object apply0()
  { return lit1; }
}

When the compiled class foo is loaded, we do:

Class fooCl = Class.forName("foo");
Procedure fooPr
  = (Procedure) fooCl.newInstance ();
// Using foo:
Object result = fooPr.apply0 ();

How does the Kawa compiler generate the appropriate Pair.make expression as shown above? In earlier versions of Kawa, a class whose instances could be literals implemented the Compilable interface. Then the compiler just called the methods in Compilable, and these would generate the code needed to re-create the literal. This had the advantage that the compiler was not limited to a few classes of literals it knew about. One problem is that it caused cross-package dependencies, since any class that could be a literal has to implement gnu.expr.Compilable. Another problem was that writing the Compilable methods required knowing how gnu.bytecode works.

The key insight is that saving compile-time literals and then restoring them at run-time is a kind of “object persistence”, similar to that offered by Java serialization. One option considered was to use standard serialization, but that required some way to store the serialized data in a class file. The article Long-Term Persistence for JavaBeans suggested an alternative. I realized that using Externalizable classes provided the more abstract serialization we needed.

Let us start with a summary: An object that can be a literal must implement the java.io.Externalizable interface. When the compiler need to generate a reference to a literal value, it calls the object's writeExternal method. The writeExternal method expects an argument that implements the java.io.ObjectOutput interface. The actual argument is a LitTable object owned by the compiler. A writeExternal method can call the standard ObjectOutput methods, such as writeObject, writeInt, and so on. The LitTable remembers the values that were passed to it in these writeObject, writeInt, etc calls, and creates an “argument list” from those values. When the writeExternal returns, the LitTable will take the argument list, and look for a matching constructor in the literal's class, using reflection. It will also look for methods named make or set. If found, the compiler will generate a call to the matching method. Simple values in the argument list will be pushed on the JVM stack directly; object references will use values generated using previous calls to writeExternal.

Here are more details on how the compiler selects which method to invoke to re-create an object. If the compiler detects a recursive writeObject call with the object as an argument while writeExternal is called on the object, then the object cyclically references itself. In that case, the compiler must take care to construct the object so that the cycle gets reproduced at run-time. This is done by first generating a call to the default constructor, and saving the result in a static field. The argument list is evaluated, with recursive references using the saved static field. Then we call a method to properly initialize the object using the evaluated argument list. The compiler looks for a method named set with a parameter list matching the argument list. If there is no such method, the compiler gives up. (In the future, we could use JavaBeans introspection, or look for a Java2 ObjectStreamField to determine how to set the properties.)

If an object does not have a cycle, the compiler first looks for a matching static method named make. If it does not find one, it looks a matching constructor. In the latter case, the compiler must also check to see if there is a zero-argument readResolve method, which Java 2 serialization uses to replace an object by a canonical object. (Kawa does not require Java 2, but LitTable does respect this Java 2 extension to serialization.) As a last resort, the compiler looks for a default constructor followed by set, as in the cycle case.

The writeExternal method of some classes may generate a variable number of values. Therefore, if a constructor or method takes an array parameter, then LitTable will consider it as matching the argument list if the latter contains an int (written using writeInt) followed by that number of arguments of the component type of the array. (One could argue that this feature is an unneeded kludge, since there is the alternative that writeExternal could just call writeObject with a single array argument, instead of calling writeObject a variable number of times. However, that would expose the internal array into the externalization protocol, which is wrong.)

Advantages of this implementation include:

R5RS defines a procedure values, which allows an expression or a function to yield multiple (or zero) values, rather then being restricted to a single result. However, the multiple values can only be passed to the call-with-values procedure. There is no automatic coercion from a multiple values to a single value, as in Common Lisp. This makes it easy to implement multiple values in a way that does not slow down code that does not use the feature, which is most Scheme code. Kawa uses a helper class Values:

class Values
{ ...
  private Object[] vals;
  public static final Values empty
    = new Values(new Object[0]);
}

The values procedure just creates a new Values object using its arguments. However, if there is only a single value, it returns the value unchanged. If there are zero values, Values.empty is returned. (This value is the same as #!void, which in Kawa is used for the result of a definition or assignment, and whose print-out is suppressed.) The Values instance is returned, with no special handling. The only part of Kawa that needs to know about Values is the call-with-values procedure; it needs to check if it was passed a Values object, or just a regular Scheme value.

This implementation satisfies the goal of no extra overhead for programs that do not use multiple values, and the cost is reasonable for programs that do. It is not as good a returning the multiple results on the stack, as some Scheme and Lisp implementations do, but that is not do-able in a Java context.

Another implementation would be needed if we want the Common Lisp behavior where multiple values are automatically coerced to the first value in single-value contexts. One way to implement that would be move the apply methods to always take an extra "continuation" parameter. Then values can check the kind of continuation it is returning to. Having the return context explicitly passed has other uses too, though it adds some extra overhead to the common case.

Scheme continuations “capture” the current execution state. They can be implemented by copying the stack, but this requires non-portable native code. Kawa continuations are implemented using Java exceptions, and can be used to prematurely exit (throw), but not to implement co-routines (which should use threads anyway).

class callcc extends Procedure1
{ ...;
  public Object apply1(Object arg1)
  {
    Procedure proc = (Procedure) arg1;
    Continuation cont
       = new Continuation ();
    try { return proc.apply1(cont); }
    catch (CalledContinuation ex)
      {
        if (ex.continuation != cont)
             throw ex;  // Re-throw.
        return ex.value;
      }
    finally
      {
        cont.mark_invalid();
      }
  }
}

This is the Procedure that implements call-with-current-continuation. It creates cont, which is the “current continuation”, and passes it to the incoming proc. If callcc catches a CalledContinuation exception it means that proc invoked some Continuation. If it is “our” continuation, return the value passed to the continuation; otherwise re-throw it up the stack until we get a matching handler.

The method mark_invalid marks a continuation as invalid, to detect unsupported invocation of cont after callcc returns. (A complete implementation of continuations would instead make sure the stacks are moved to the heap, so they can be returned to an an arbitarry future time.)

class Continuation extends Procedure1
{ ...;
  public Object apply1(Object arg1)
  {
    throw new CalledContinuation
	      (arg1, this);
  }
}

A Continuation is the actual continuation object that is passed to callcc's argument; when it is invoked, it throws a CalledContinuation that contains the continuation and the value returned.

class CalledContinuation
    extends RuntimeException
{ ...;
  Object value;
  Continuation continuation;
  public CalledContinuation
    (Object value, Continuation cont)
  {
    this.value = value;
    this.continuation = cont;
  }
}

CalledContinuation is the exception that is thrown when the continuation is invoked.

Scheme requires that tail-calls be implemented without causing stack growth. This means that if the last action of a procedure is another function call, then the called function's activation frame needs to be discarded before the new function's frame is allocated. In that case, unbounded tail-recursion does not grow the stack beyond a bounded size, and iteration (looping) is the same as tail-recursion. Making this work is easy using a suitable procedure calling convention, but this is difficult to do portably in Java (or for that matter in C), since implementing it efficiently requires low-level procedure stack manipulation.

Compiler optimizations can re-write many tail-calls into gotos. The most important case is self-tail-calls or tail recursion. Kawa rewrites these to be a simple goto to the start of the procedure, when it can prove that is safe. Specifically, it does optimize Scheme's standard looping forms do and named-let.

Implementing general tail-calls and continuations require being able to manipulate the procedure call stack. Many environments, including the Java VM, do not allow direct manipulation of stack frames. You have the same problem if you want to translate to portable C, without assembly language kludges. Hence, you cannot use the C or Java stack for the call stack, but instead have to explicitly manage the call graph and return addresses. Such re-writing has been done before for ML [MLtoC] and Scheme [RScheme].

In Java we have the extra complication that we do not have function addresess, and no efficient way to work with labels. Instead, we can simulate code labels by using switch labels. This is more overhead than regular method calls, so the regular Procedure interface discussed earlier will probably remain the default. Thus some procedures use the regular calling convention, and others the “CPS” (Continuation Passing Style) calling convention. The rest of this section explains the planned CPS calling convention.

public abstract class CpsFrame
{
  CpsFrame caller;
  int saved_pc;
}

Each CpsFrame represents a procedure activation. The caller field points to the caller's frame, while saver_pc is a switch label representing the location in the caller.

There is a single “global” CpsContext which owns the generalized call “stack”. There may be many CpsContext if there are multiple threads, and in fact one CpsContext is allocated each time a regular (non-CPS) method calls a procedure that uses the CPS calling convention.

public class CpsContext
{
  CpsFrame frame;
  int pc;
  Object value;

  Object run()
  {
    while (frame != null)
      frame.do_step(this);
    return value;
  }
}

Each CpsContext has a frame which points to the currently executing procedure frame, and pc which is a case label for the code to be executed next in the current procedure. The result of a function is left in the value field. All of these these fields may be imagined as global (or per-thread) registers, which is how you would ideally like to implement a CPS calling convention if you had access to machine registers. The frame, pc, and value fields simulate the frame pointer register, the program counter, and the function result register in a typical computer. After creating a CpsContext with an initial frame and pc, you would call run, which uses the do_step method to execute each step of a function until we return from the initial frame with a final value.

Consider a simple Scheme source file, which defines two functions:

(define (f)
  (g)
  (h))
(define (g)
  ...)

This would get compiled into:

public foo extends CpsFrame
{
  void do_step(CpsContext context)
  {
    CpsFrame fr;
    switch (context.pc)
    {
      case 0: // top-level code
        define("f", new CpsProc(this, 1);
        define("g", new CpsProc(this, 3);
        return;
      case 1: // beginning of f
        // do a (non-tail) call of g:
        fr = g.allocFrame(context);
        fr.caller = this;
        fr.saved_pc = 2;
        context.frame = fr;
        return;
      case 2:
        // then do a tail call of h:
        fr = h.allocFrame(context);
        fr.caller = this.caller;
        fr.saved_pc = this.saved_pc;
        context.frame = fr;
        return;
      case 3:  /* beginning of g */
        ...;
    }
  }
}

The entire code of the Scheme compilation unit is compiled into one large switch statement. Case 0 represents the top-level actions of the program, which defines the functions f and g. Next comes the code for f, followed by the (omitted) code for g. When f is called, a new foo frame is allocated, and the context's pc is set to 1, the start of f.

The body of f makes two function calls, one a non-tail function, and finally a tail-call. Either call allocates a CpsFrame and makes it the current one, before returning to the the main loop of CpsContext's run method. The regular (non-tail) call saves the old current frame in the new frame's return link. In contrast, the tail call makes the return link of the new frame be the old frame's return link. When we return then from do_step, the old frame is not part of the call chain (unless it has been captured by callcc), and so it has become garbage that can be collected.

At the time of writing, the CPS calling convention has not been implemented, but I am filling in the details. It has some extra overhead, but also a few side benefits. One is that we compile an entire source file to a single Java class, and it is more convenient when there is a one-to-one correspondence between source files and binary files (for example in Makefiles).

Another exciting possibility is that we can write a debugger in pure Java, because we can run do_step until some condition (break-point), examine the CpsFrame stack, and optionally continue.