define Node as { int data, Tree left, Tree right }
define Tree as null | Node

// Insert item into tree
Tree insert(Tree tree, int item):
    if tree is null:
        return {
          data: item,
          left: null,
          right: null
        }
    else if item < tree.data:
        tree.left = insert(tree.left,item)
    else:
        tree.right = insert(tree.right,item)
    // done
    return tree

Here, Whiley’s flow typing system automatically retypes the variable tree to Node on the false branch of the condition tree is null. Thus, we can safely use tree.left and tree.right without having to explicitly cast tree to a Node. In this way, we see that variable tree has different types at different points. In this case, it always has one of the following types: Tree, Node or null (the latter being its type on the true branch of the condition tree is null).

In the above example, the different types of tree are related — i.e. Node and null are both subtypes of Tree. However, Whiley’s flow typing system can also work with unrelated types. A more involved example, based on my Chess benchmark, illustrates:

define LongPos as { int col, int row }
define LongMove as {
  Piece piece,
  LongPos from,
  LongPos to
}

define ShortPos as {int row} | {int col}
define ShortMove as {
  Piece piece,
  ShortPos from,
  LongPos to
}

// Find matching pieces on the board.
[Pos] find(Piece p, Board b):
    ...

// Intersect destination with possible moves of matching pieces.
[Pos] narrow(ShortMove m, [Pos] ms, Board b):
    ...

// Convert move in short notation into long notation.
LongMove convert(ShortMove m, Board b) throws Error:
    matches = find(m.piece,b)
    matches = narrow(m.to,matches,b)
    if |matches| != 1:
        throw Error("invalid move")
    m.from = matches[0]
    return m

This code converts moves expressed in short algebraic notation into long algebraic notation (see this for more). In the short notation, moves are given in an abbreviated (and potentially ambiguous) form with only the destination square given. For example, a move Nf6 indicates a Knight moving to square f6. If the player has only one knight, then the move must refer to it. However, if there are two Knights, the system must determine which it is. This is done by narrow() above, which intersects the destination with the possible moves of the matching pieces. In the case of multiple matches, an Error is thrown. The notation also permits explicit disambiguation by providing either the rank or file of the given piece. For example, Neg3 indicates the Knight on file e moves to square g3.

Flow typing is crucial in type checking the above fragment. The critical issue resolves around the statement m.from = matches[0]. This retypes variable m from ShortMove to LongMove, allowing the subsequent statement return m to be type checked. In this case, there is no subtyping relationship between ShortMove and LongMove — they are essentially unrelated.

A Problem of Termination

We now come to the main topic of this post. Consider the following very simple example:

define Rec as int | { Rec f }

Rec loopy(int x, int y):
  z = { f : x }
  while x < y:
     z.f = z
     x = x + 1
  return z

This program currently causes the Whiley Compiler to enter an infinite loop! But, why is that? Well, the key is that flow typing is implemented in the style of a dataflow analysis. Roughly speaking, the algorithm employs an environment which maps variables to their current type. It then processes each statement updating the environment as it proceeds. The following illustrates the process for the first two statements above:

Rec loopy(int x, int y):
  // x->int, y->int
  z = { f : x }
  // x=>int, y=>int, z=>{int f}
  ...

In many ways, this is the natural way to implement the flow typing algorithm and follows, for example, the approach used in the JVM bytecode verifier (perhaps the most widely used example of flow typing).

So, why does the above short program not terminate? Well, a dataflow analysis handles loops by iterating until a fixed-point is reached. This is done by first propagating through the loop body to update the environment, like so:

  // x=>int, y=>int, z=>{int f}
  while x < y:
      // x=>int, y=>int, z=>{int f}
      z.f = z
      // x=>int, y=>int, z=>{{int f] f}
      x = x + 1
      // x=>int, y=>int, z=>{{int f] f}

At this point, it merges the new environment with that originally going into the loop and repeats the process:

  // x=>int, y=>int, z=>{int f}
  while x < y:
      // x=>int, y=>int, z=>{{int f}|int f}
      z.f = z
      // x=>int, y=>int, z=>{{{int f}|int f} f}
      x = x + 1
      // x=>int, y=>int, z=>{{{int f}|int f} f}

And then repeats again:

  // x=>int, y=>int, z=>{int f}
  while x < y:
      // x=>int, y=>int, z=>{{{int f}|int f} f}
      z.f = z
      // x=>int, y=>int, z=>{{{{int f}|int f} f} f}
      x = x + 1
      // x=>int, y=>int, z=>{{{{int f}|int f} f} f}

And so on, until there is no change in the environment (i.e. the fixed point is reached). For a typical dataflow analysis, this should happen within a few iterations. However, for the above flow typing algorithm, this process will never terminate because it is constructing successively larger types for variable z.

In fact, we can obtain a valid flow-typing for our simple program as the following illustrates:

Rec loopy(int x, int y):
  // x->int, y->int
  z = { f : x }
  // x=>int, y=>int, z=>{int f}
  while x < y:
      // x=>int, y=>int, z=>{Rec f}
      z.f = z
      // x=>int, y=>int, z=>{Rec f}
      x = x + 1
   // x=>int, y=>int, z=>{Rec f}
   return z

The key is that assigning {Rec f} to field f gives the type {{Rec f} f} — which is a subtype of {Rec f}. Hence, the above typing is valid (albeit conservative). The problem is how to go about finding this typing, given that the standard dataflow approach does not succeed.

At this point, I’m not going to say too much more. That’s because I’ve written up a detailed account of the solution in a technical report. The key idea is to use a constraint-based approach, rather than a dataflow approach. Whilst this is slightly more complex, it has one important advantage: the algorithm always terminates!

Anyway, this post is not really about Eclipse plugins.  One of things I had to do, was integrate my own build framework into that of Eclipse.  This immediately caused problems because of the Eclipse CoreException.  This checked exception is required on a large number of methods.  The problem is that my build framework requires the standard java.io.IOException on several methods, but CoreException does not extend this. Since I don’t want my build framework to depend on Eclipse, I’m forced into doing something unusual. For example, tunneling CoreExceptions through my framework as IOExceptions and vice-versa through Eclipse. One could perhaps argue that CoreException should (or should not) implement IOException — but, that’s not what this post is really about.

So, what is this post about? Well, this issue got me thinking: are checked exceptions always caused by I/O?

Let’s try a simple thought experiment to get us thinking about this. Imagine a program running on bare metal which does not perform any I/O whatsoever. The question is: in what ways can this program go wrong (i.e. crash)? There are some obvious ones:

1. Segmentation Fault (or similar).  For example, it tried to dereference a null pointer, divide by zero or access an array out-of-bounds, etc.
2. Out-of-memory. The program ran out of memory and e.g. dumped its core.
3. Infinite Loop. The program entered into some kind of infinite loop and continued forever.
4. Deadlock. The program managed to enter some kind of dead lock (or even a live lock) and failed to make progress.

Maybe there are some others, but this mostly covers it (remember, I/O is not permitted so we can’t e.g. block indefinitely on a socket).  I want to argue that none of these things should cause a checked exception. You might think that’s obvious because e.g. in Java none of these things is a checked exception (e.g. NullPointerException, ArithmeticException, OutOfMemoryError, etc, are unchecked).  But, as usual, it is more subtle than it first looks…

So, how could the above things cause a checked exception? Well, the programmer will obviously try and protect against them happening.  For any given function, there are two main ways this can play out:

• In some cases, he/she will simply conclude that: if the function is written correctly and called with valid arguments, an error could never happen (e.g. divide-by-zero, out-of-bounds, infinite loop, etc). In these cases, he/she generally won’t to do anything specific (except perhaps a little bit of argument checking).
• In other cases, he/she will conclude that: this function must accept all inputs, but some of them are incorrect.  A good example is a parse(String) function which parses a string and e.g. converts it into a data structure. In the case of a malformed string, it must report a SyntaxError.  The programmer may decide to implement this as a checked exception, so that any callers of the function are forced to acknowledge this possibility.

These two cases may seem similar, but there is an important difference: in one case, our function only accepts “correct” inputs; in the other, it must also accept “incorrect” inputs.  Still, this seems fairly straightforward …

Consider again our thought experiment in the context of the parse(String) function, which throws SyntaxError (a checked exception). Here’s the line of reasoning: Q) Under what circumstances could a SyntaxError be thrown? A) If the input string was invalid; Q) How could the input string be invalid? A) If the programmer constructed an invalid string; Q) How could the programmer have constructed an invalid string? A) If he/she had made a programming error. The thing is, since there is no I/O, the programmer has complete control over exactly what strings are constructed. If an invalid string was constructed, it is because the programmer made a mistake somewhere. That’s the only possibility.

If you’ve made it this far, great! Hopefully, you’re starting to get the idea: without I/O, there’s really no need for checked exceptions. The problem, of course, is that we do have I/O. But, actually, it’s worse than that. I won’t complain about having to write throws IOException on a function which can throw an IOException. The problem is having to write it on a function which definitely cannot throw an IOException. For example, I might call parse() from a setting where the input string is always syntactically valid. But, I cannot tell the compiler this — so I’ll probably have to catch the SyntaxError and just discard it. Maybe that’s not so bad, but it’s definitely one of the reasons checked exceptions have a bad reputation.

Finally, the other reason people get upset with checked exceptions is when they are used incorrectly. Based on my above analysis, my conclusion is that Eclipse’s CoreException should extend IOException. In fact, I think probably all checked exceptions should extend IOException …

ChangeLog

• Deployed the new Whiley Build System, which provides a generic framework for managing namespaces and package roots.  This is currently lacking good support for dependency tracking, but it should be easy enough to extend to support this.
• Fixed quite a few bugs, and have identified quite a few more to be fixed.

// find lowest index of matching entry, or return -1 if no match
int findLowest(sorted arr, int value) {
   int index = Arrays.binarySearch(arr,value)
   if(index < 0) { return -1; } // no match
   // matched, so find lowest index
   index = index - 1;
   while(index >= 0 && arr[index] == value) {
       index = index - 1;
   }
   return index + 1;
}

I often find a method like this useful because, when there are multiple ints of the same value, Arrays.binarySearch() doesn’t guarantee which is found.

Of course, the above isn’t legal Java though! That’s because there is no way to alias a name (e.g. sorted) with a type (e.g. int[]). Now hold on, you say: you can just use int[] above, instead of sorted, and it will work fine! True. But, I want to use sorted to better document my program. In C, you could use a typedeffor this, and I’ve often found that useful.

So, overall, I think allowing such “type aliases” in Java would help: firstly, by providing better documentation; secondly, by allowing them to be type checked. Now, there are quite a few gritty details to work out, such as the actual syntax for declaring a type alias. I’m not proposing a JSR or anything here, but how about this:

alias sorted of int[]

// find lowest index of matching entry, or return -1 if no match
int findLowest(sorted arr, int value) {
   ...
}

Seems simple enough. Now, if we want aliases to be type checked, then we need a way to turn a given type (e.g. int[]) into an alias (e.g. sorted). Well, I suppose a plain-old cast could do the job:

alias sorted of int[]

// find lowest index of matching entry, or return -1 if no match
int findLowest(sorted arr, int value) {
   ...
}

sorted createSorted(int[] unsorted) {
   Arrays.sort(unsorted);
   return (sorted) unsorted;
}

Those type theorists amongst you will immediately raise your arms: what if we subsequently update unsorted and break the sorting guarantee? Well, yup, that could happen. And, without something like uniqueness types, there’s not much we can do. But, perhaps we can just live with it, given that we’re already living with similar issues related to generics and erasure.

Anyhow, it’s just a thought. And, I’m obviously not the first person to some with this idea (see e.g. this, this and this).

package zlib.core

import Console from whiley.lang.System
import zlib.util.BitBuffer

Here, we have two modules that must exist in the global namespace: whiley.lang.System and zlib.util.BitBuffer. As with Java, they co-exist in the same namespace, but do not necessarily originate from the same physical location (i.e. whiley.lang.System is located in the wyrt.jar, whilst zlib.util.BitBuffer is in a file system directory somewhere).

The Whiley compiler takes care of this through the Path.ID and Path.Root abstractions.  A Path.ID represents a hierarchical name in the global namespace (e.g. whiley.lang.System); a Path.Root represents a physical location which forms the root of a name hierarchy (e.g. a jar file or a directory). Thus, the global namespace is made up from multiple roots and, to find a given item, we traverse them looking for it (we’ll ignore the possibility of collisions for simplicity). To illustrate, here’s the (slightly simplified) Path.ID interface:

public interface ID {

  /**
   * Get number of components in this ID.
   * ...
   */
  public int size();

  /**
   * Return the component at a given index.
   * ...
   */
  public String get(int index);

  /**
   * Get last component of this path ID.
   * ...
   */
  public String last();

  /**
   * Get parent of this path ID.
   * ...
   */
  public ID parent();

  /**
   * Append component onto end of this id.
   * ...
   */
  public ID append(String component);
}

This all seems simple enough, right? Well, yeah it is!

So, what’s up? Well, the thing is, the Whiley compiler is not the first system to address this problem! Eclipse, for example, adopts a similar approach through the IPath interface. A cut-down version of this interface is:

public interface IPath {
  /**
   * Returns the specified segment of this path, ...
   * ...
   */
  public String segment(int index);

  /**
   * Returns the last segment of this path, ...
   * ...
   */
  public String lastSegment();

  /**
   * Returns the number of segments in this path.
   * ...
   */
  public int segmentCount();

  /**
   * Returns whether this path is a prefix of the given path.
   * ...
   */
  public int isPrefixOf(IPath path);

  /**
   * Return absolute path with segments and device id.
   * ...
   */
  public IPath makeAbsolute(IPath path);

  ...
}

Hopefully, you’ll notice both similarity and difference between the Path.ID and IPath interfaces. In fact, IPath has quite a few more methods which are not present in Path.ID. However, it should be clear that the functionality described by Path.ID is a subset of that described by IPath (albeit with slightly different names).

Obviously, I want to integrate the Whiley compiler with Eclipse (i.e. make an Eclipse plugin for Whiley). At the same time, I want to reuse as much of Eclipse’s functionality as possible within my plugin — otherwise, I’m just adding more bloat to an already bloated system, and potentially compromising the effectiveness of my plugin. I’m prepared to go to some lengths to enable this, even to the point of changing my Path.ID interface to bring it more inline with IPath; however, I’m not prepared to make the Whiley Compiler depend upon Eclipse — that is, no import org.eclipse..* statements in the Whiley compiler.

How can I do this? Well, the obvious solution is to provide an Adaptor in the plugin which implements Path.ID and wraps an IPath. This probably requires adding a Factory interface (e.g. Path.Factory) for creating Path.ID instances, since the Whiley compiler needs the ability to construct Path.ID instances and test for their validity.

The adaptor works, right? Yeah, it does. But, it amounts to layering one abstraction on top of another when they’re really the same thing. It would be nice if there was a mechanism for binding abstractions together. For example, in the Eclipse Plugin, it would let me say: let an IPath be a valid Path.ID with the following binding between names. But, perhaps that’s too much wishful thinking…

You can find the complete code for my PNG decoder here.  To compile it, you’ll probably need to checkout the latest development snapshot of the Whiley compiler.  At the moment, it doesn’t run too fast either … but that’s mostly because arithmetic in Whiley is unbounded and, hence, relatively slow. Eventually, I will optimise most of this overhead away.

Filtering

The PNG format is interesting because it employs filtering at the scanline level.  This means it applies one of five possible functions to each scanline in order to increase the amount of order and, hence, improve the compression ratio.  For some reason, I got particularly stuck debugging this part.  The bugs, however, produced some interesting effects:

(original)

(without filtering)

(bug in Paeth Predictor)

Constraints

Another interesting aspect of the PNG format are the constraints imposed on its data values.  The following excerpt from the spec defines constraints on the PNG header:

The IHDR chunk shall be the first chunk in the PNG datastream. It contains:

Width	4 bytes
Height	4 bytes
Bit depth	1 byte
Colour type	1 byte
Compression method	1 byte
Filter method	1 byte
Interlace method	1 byte

Width and height give the image dimensions in pixels. They are PNG four-byte unsigned integers. Zero is an invalid value.

Bit depth is a single-byte integer giving the number of bits per sample or per palette index (not per pixel). Valid values are 1, 2, 4, 8, and 16, although not all values are allowed for all colour types. See 6.1: Colour types and values.

Colour type is a single-byte integer that defines the PNG image type. Valid values are 0, 2, 3, 4, and 6.

Bit depth restrictions for each colour type are imposed to simplify implementations and to prohibit combinations that do not compress well.

These constraints are particularly interesting because, in Whiley, I can represent them directly in the code.  The following illustrates the PNG header abstraction:

public define ValidColorDepths as [
 {1,2,4,8,16}, // GREYSCALE
 {},           // (empty)
 {8,16},       // TRUECOLOR
 ...
]

public define IHDR as { // Image Header
  u32 width,
  u32 height,
  BitDepth bitDepth,
  ColorType colorType,
  ...
} where width > 0 && height > 0 && bitDepth in ValidColorDepths[colorType]

Here, we can see the constraints on the width, height and bitdepth are encoded directly into the program. Currently, violation of these constraints results in a runtime assertion failure. In the future, the aim is to check them at compile time.

Conclusion

It’s been fun learning about the PNG and GIF file formats.  And, of course, writing realistic benchmarks provides extremely helpful feedback on the language design.  All up, I’m very pleased to see that writing programs in Whiley was an enjoyable experience!  There’s a long way to go yet though, as writing these benchmarks has uncovered a bunch of compiler bugs for me to work on over the coming weeks and months …

In an effort to help me get a good handle on the problem, I’m going to try and enumerate the main issues here.  With any luck, the answer will just pop out …

Overview

The main task of the front-end is to convert Whiley source code into the Wyil intermediate bytecode.  The key aspects of Wyil are:

1. Wyil is an unstructured intermediate language, whose programs are composed of bytecodes (similar in many ways to Java Bytecode).
2. All names used in Wyil bytecodes are fully resolved (i.e. they include appropriate package and module identifiers).
3. All Wyil bytecodes are associated with an appropriate type.  For example, the type of a length bytecode must be an effective collection (i.e. an effective list, set, dictionary or string).
4. All constraints should be expanded (or, at least, partially expanded)

As an example, consider this Whiley program for summing a list of naturals:

import nat from whiley.lang.Int

public int sum([nat] list):
    r = 0
    for i in list:
        r = r + i
    return r

This is compiled into the following Wyil bytecodes:

public int sum([int] list):
requires:
    load 0 : [int]
    forall 2 : [int]
        load 2 : int
        const 0 : int
        ifge goto exitlab : int
        fail "constraint not satisfied"
    .exitlab
body:
    var r, i
    const 0 : int
    store r : int
    load list : [int]
    forall i : [int]
        load r : int
        load i : int
        add : int
        store r : int
    load r : int
    return : int

We can see that the type nat has been expanded to int by looking at its definition in whiley.lang.Int. The requires clause represents the expanded constraints generated from [nat] — namely, that every element of list should be non-negative.

Resolution

An important aspect of converting Whiley source into Wyil is resolution.  This is about determining what a given name in a source file actually corresponds to by looking it up in the WHILEYPATH following the given import statements.  As part of this, types and constants must be expanded into fully resolved types and constants.  For example, consider this:

Light.java:

define Light as {
  Point point,
  Colour colour
}

...

Scene.java:

import Light

define Scene as {
 [Light] lights,
 [Object] objects
}

...

private Colour colourAt(Light light, Point pt):
   ...

In order to fully resolve the type Scene, we must resolve the type Light. This involves, firstly, determining what module Light is defined is (by following the import trail) and, secondly, what Light‘s fully resolved type is.  Similarly, we must trawl the source code of functions (e.g. colourAt) and resolved any names referred to (in this case, the type of parameter light).

Resolution is an inherently global task, since types obviously may be defined in terms of types in other modules.  Furthermore, types may be recursive across modules and modules may have dependencies going in both direction (e.g. type X in one module refers to type Y in another, whilst type Z in the latter refers to a type in the first, etc).

Flow Typing

The second major task faced in converting Whiley source into Wyil bytecodes is that of flow typing.  This is the process of determining a type for every expression and statement in the program, including all intermediate expressions used.  During this process some ambiguity between different expressions with the same syntax will be resolved (e.g. x+y can be either arithmetic addition, or set union — and we can only determine this when we know the types of x and y).

Looking at a similar example to before, we can see roughly how flow typing proceeds:

real sum([real] list):
   r = 0           // r => int, based on type of constant 0
   for v in list:  // v => real, based on type of list
      r = r + v   // r => real, based on type of operands
   return r       // r => real|int, based on type of r after loop

The key difficulty with flow-typing is that is an inherently flow-sensitive activity, which is particularly problematic in the presence of exceptions and retyping expressions (i.e. those involving is).

Two Differing Approaches

One of the key design issues in the compiler front-end is the choice of when to convert from the source-level AST into the Wyil bytecodes.  There are essentially two main approaches:

1. (Late-Generation) Here, flow-typing is performed directly on the AST which is subsequently converted into Wyil bytecodes.
2. (Early-Generation) Here, the AST is first converted into temporary Wyil bytecodes which are then flow-typed to produced the final bytecodes.

For some reason, the choice of which approach to take has caused me a lot of headaches.  I believe either can be made to work.  The issue, of course, is in finding the simplest most coherent approach.  This always seems to save me time in the long run.  One reason for this is that generation is intertwined with constraint expansion (that is, generating Wyil bytecodes corresponding to source-level constraints).  The main trade-offs are:

• Late-Generation. This is probably the most logical approach.  However, it is harder to properly flow-type the AST because of retyping (i.e. is) expressions.  On the other hand, there is potential to support retyping of complex retyping (e.g. involving records and possibly lists).  This approach also requires an awkward abstraction which I refer to the as “unconstrained types”.
• Early-Generation. This is awkward because it requires special abstract bytecodes to encode ambiguous expressions which can only be resolved when types are known (the trickiest being related to the various kinds of method invocation).  However, flow-typing is much simplified because it operates on the unstructured intermediate language where flow-sensitive analysis is easier.  There is also no need to support the notion of an “unconstrained type”.  Another downs-side of this approach is that it relies on Wyil bytecodes being able to encode nominal types.  However, I want to support this anyway in order to simplify debugging Wyil code.

The issue of unconstrained types is slighty odd.  It stems from a separation from expanding types and expanding constraints.  For example, consider this:

define nat as int where $ >= 0

int f(nat|[int] x):
    if x is nat:
        return 0
    else:
        return |x|

Currently, this program should (in fact) fail compilation because x must have type int|[int] on the false branch.  The notion of unconstrained types handles this by replaced all constrained types with void before computing the type difference on the false branch.  If the constrained was expanded before type checking this function, then there would be no need for an unconstrained type as it would be implicit.  Things get particularly awkward when we consider types in compiled libraries, since one cannot retro-actively determine the unconstrained type.  Instead, for every type, we’ll have to embed the unconstrained version as well.

Ok, that’s it for now.  I’m not sure how much this is helping me, but I probably need to add more of the subtle trade-offs as I remember them.

ChangeLog

• Fixed outstanding problem with list and set types related to type tests.  More specifically, on the negative branch of a type test the correct type was not always being calculated.
• Added support for open records.
• Added a CONTRIBUTORS file for recording project contributors.  This is based on the developers certificate of origin used by the Linux Kernel.
• Changed syntax for processes to be now “references”.  This avoids conflicting the name with OS processes.  So, e.g. type process T becomes ref T.
• Changed syntax for dereferncing objects to use * and ->, similar to C.
• Changed syntax for maps from e.g. {1->2} to {1=>2}.  This is to avoid conflict with -> for dereferencing.
• Changed syntax for processes to syntax for references.  So, e.g. type process {int x} becomes ref {int x}.  The motivation for this choice is simply to avoid confusion with OS processes.
• Changed Wyil bytecode to support various “effective” types (e.g. sets, lists, dictionaries).  These enable more efficient operation across a union of similarly kinded types.  For example, we can index into a list of type [int]|[bool] without having to coerce into a list of type [int|bool].
• Worked hard to get constraints being expanded properly again.  This is working pretty well now for the most part.
• Added support for Maven compilation (thanks Lee).

1. The first was an excellent article entitled “Welcome to the Hardware Jungle” by Herb Sutter. This article is about the coming advent our multicore overlords. Whilst this might sound like something you’ve heard before, it’s actually well worth the read. His argument is that heterogeneous massively-multicore computing is fast becoming the norm, and there is no turning back. I found the article quite scary, as I can’t imagine programming in the extreme environment suggested. I also have to question whether everyday applications will really benefit from massive multicore. But, clearly, I can see that quite a few will.
2. The second was the following (short) youtube video of Simon Peyton Jones and Erik Meijer discussing the space of programming languages:

   Simon talks about how both imperative and functional programming languages are trying to reach some kind of “Nirvana”, but coming at it from different directions.

Now, the question is: how do they connect together? Well, essentially, I think the “Nirvana” space the Simon talks about is exactly the space we need to deal with the Hardware Jungle. In other words, I think it’s the space most suitable for distributed and parallel computing.

What do we know about this “Nirvana” space? In the video, Simon talks about safe and unsafe languages. He says explicitly that safe means having limited or highly controlled side-effects. Languages which are unsafe by his categorisation include Java, C#, C, and the majority of languages traditionally thought of as imperative or object oriented. They are unsafe because one cannot reason about the result of any given method in isolation from others. That is, methods may read/write shared state (via the heap) and, to reason about them, we must know: (1) what shared state is actually accessed; (2) what value it has when it is accessed. These three requirements make it very difficult know what’s going on, particularly if something else could modify the state at any point. More importantly, I believe, is that these requirements make it very difficult for the compiler to reason about what’s going on.

What does this have to do with the Hardware Jungle? Well, I believe there are two important points here:

1. To move the right data for a given computation onto the right core, we must know exactly what state that computation will access.
2. For massively multi-core systems, Humans will not be capable of optimally mapping resources onto cores. We will increasingly rely on sophisticated algorithms to do this for us. Typically, such algorithms will be embedded in the compiler and/or runtime system.

These two points taken together imply it must be possible to automatically determine what state a given computation will access. The easiest way of doing this is to aggressively restrict the state that can be accessed by requiring pure functions. Furthermore, I believe it is not sufficient to rely on the programmer to ensure his/her functions are pure — the compiler must do this for us. This is because race-conditions are already notoriously difficult to debug and in the Hardware Jungle things will get seriously crazy.

This leads me to the final and, I think, most important question:

Which mainstream programming languages currently support pure functions and/or other mechanisms for aggressively limiting side-effects?

Haskell is clearly one example, D is another. But, what else?

UPDATE: Thanks to Evan for suggesting upload the slides as well — you can get them here!

An Example

So, what does this all mean? Well, let’s have a look at an examples:

[real] normalise([real] data, real max):
    for i in 0..|data|:
        data[i] = data[i] / max
    return data

void ::main(System sys):
    original = [1.2,2.3,4.5]
    normalised = normalise(original,0.5)
    sys.out.println(original)
    sys.out.println(normalised)

This function updates a list of real values in-place using a typical (imperative) list assignment of the form data[i] = ....  In Java, where variables of array type are references to array objects, this would simultaneously update the callers version of this array as well.  In Whiley, however, this is not the case.  The list assignment inside normalise() does not modify the original list in main().  This is because the list is passed-by-value in the true sense of the word.  You can think of this as meaning that the whole list is copied when the normalise function is called to prevent any interference between caller and callee.

(In)efficiency?

Ok, but that all that copying must be crazily inefficient! Well, not so.  This is because, whilst the semantics of Whiley dictate pass-by-value for compound structures, the underlying implementation actually passes them by reference.  Furthermore, it clones them lazily with reference counting being employed to reduce the situations where a clone is actually required.  Before explaining how the reference counting works, let’s look at some actual data first:

What is this data showing us? Well, “# Clones” shows the number of clones actually performed versus the number that a naive implementation of value semantics would have performed.   The naive version clones whenever an argument is passed or returned from a function, whenever a list element is assigned, etc.  It represents an upper bound on the number of clones required.  So, for example, looking at the Gunzip benchmark we see that only 873 clones were required out of a maximum of 140561.  This indicates that, in the vast majority of cases, value semantics does not actually result in many extra clones.

But the results for Jasm look quite bad? Well, yes.  But, actually, they’re not too bad if we consider the cause.  Essentially, the Jasm benchmark consists of an inner loop for decoding bytecodes.  Roughly speaking, it looks like this:

([Bytecode],int) decode([byte] data, int pos):
    opcode = Byte.toUnsignedInt(data[pos])
    kind,fmt,type = decodeTable[opcode]
    switch fmt:
        case FMT_EMPTY,
            ....
        case FMT_I8:
            idx = Byte.toUnsignedInt(data[pos+1..pos+2])
            return {offset: pos-14, op: opcode},pos+2
        case FMT_I16:
            idx = Byte.toUnsignedInt(data[pos+3..pos+1])
            return {offset: pos-14, op: opcode},pos+3
        case FMT_VARIDX:
            index = Byte.toUnsignedInt(data[pos+1..pos+2])
            return VarIndex(pos-14, opcode, index),pos+2
        ...

What we see is that the loop first reads the opcode byte and then, based on this, reads zero or more additional bytes  (e.g. data[pos+1..pos+2]).  This sublist operation is the root cause of almost every  clone reported in the above table for Jasm.  In fact, it’s not a clone of the entire data list; rather, it just copies those few bytes being read into a new list — meaning it’s not really very expensive.

Implementation

So, how does the reference counting work? One of the key optimisations is knowledge of when a variable is no longer live. For example:

[int] f([int] xs):
   ys = xs // ref count not increased
   ys[0] = 1
   return ys

Here, the variable xs is dead after the assignment to ys.  Therefore, we don’t need to increase the reference count of the object it refers to as, effectively, ownership is transferred from xs to ys.  If the reference count of xs on entry was 1, then it will still be 1 at the assignment ys[0] = 1 and, hence, the assignment can be performed in place.  Now, let’s consider a more detailed example:

  [int] f([int] z):
      z[0] = 1 // Object #2 created
      return z

  [int] g():
      x = [1,2,3] // Object #1 created
      y = f(x)
      return x + y

On Line 6, Object #1 (which represents the constructed list) has an initial reference count of one. This does not change when it is assigned to x. Its reference count is then increased by one on Line 7, as x is used in the invocation expression and remains live afterward. On entry to f(), parameter z refers to Object #1, which now has reference count two. Therefore, the list assignment on Line 2 creates an entirely new object before updating it. It also decrements the reference count of Object #1. On Line 8, x still refers to Object #1 (now with reference count one) and, hence, the append is performed in place without cloning.

Conclusion

Reference counting is a critical optimisation to improving the performance of Whiley programs.  The latest version of the compiler (finally) supports this, although there is still room for considerable improvement.  In fact, a good starting point is the following paper:

• Staged Static Techniques to Efficiently Implement Array Copy Semantics in a MATLAB JIT Compiler, N. Lameed and L. Hendren.  In Proceedings of the Conference on Compiler Construction, 2011. [PDF]

Anyway, that’s all folks!

class Parent { ... }
class Child extends Parent {... } // invalid: parent implicitly final

In place of final we would have another modifier, say open.  This would allow us to extend classes like so:

open class Parent { ... }
class Child extends Parent { ... } // valid: parent explicitly open

Now, the question is: why do I think final should be the default? It’s got nothing to do with performance.  The following quotes from Josh Bloch’s excellent talk on API design (see [1][2][3]) gives us a clue:

“When in doubt, leave it out”

“You can always add, but you can never remove”

What does this mean? If you’re not sure whether a function should be included, then don’t include it.  That’s because, once you’ve included a function in a public API, people will depend upon it and you’ll have to maintain it.  If it’s badly designed, you’re stuck with it.  Sure, you can try and deprecate it — but you’ll probably end up keeping it forever anyway.

What has all this got to do with final classes? Well, a non-final class can be extended of course!  Any public or protected methods can be overridden and protected fields read/written.   More importantly, you cannot reverse the decision — i.e. once a public non-final class, always a public non-final class.  In contrast, when using final as the default for classes, you can reverse your decision — i.e. you can always open, but you can never close.

This observation is hardly rocket science!  Josh Bloch in his (also excellent) book Effective Java states “you should make each class or member as inaccessible as possible”.  For example, you should always prefer private to protected fields. For some reason though, he doesn’t extend this to include preferring final to non-final classes.

And, it looks like there are at least some like-minded people out there and, of course, there are those who think differently …

ChangeLog

• Added support for proper reference counting of compound structures.  This employs a live variables analysis to determine when a local variable is dead.
• Reworked the name resolution and module loading system.  This was done primarily to support build tools such as ant and eclipse.
• Improved the Ant task.
• Further improved the runtime checking of constraints.
• Added some rudimentary reporting of memory usage by the various compiler stages.

Now, the thing is: not all my end-end tests are currently passing.  In fact, I don’t think it’s ever been the case that all of the tests have passed.  That may seem like a bad thing, but I think there are some mitigating circumstances:

1. My test suite is constantly growing.  As soon as I spot an error, or think of a possible problem, I add a test.  Adding tests makes me feel good, and I love it!  That’s because a test is a piece of knowledge locked-in.  Once the test is written and checked in, I can’t forget.
2. Some failures represent issues that I’ve given very low priority to.  Eventually, I will get to them … but not yet.  I do sometimes make use of the @Ignore annotation for these kinds of tests.
3. Some failures represent significant design flaws in the system.  They should be high-priority, but represent weeks or months of refactoring and redesigning to fix.  I don’t like to @Ignore these ones … I prefer to feel the pain.

In a way, my test suite is like a queue.  My tests never all pass because by the time I fixed all the ones that are failing … I’ve added some more!

This is similar to Test-driven development I suppose.  What I don’t like about TDD though, is that you’re supposed to write a test and then immediately make it pass.  That doesn’t work for me since,  in a few seconds, I can write a test that might takes months of careful refactoring to solve.   I’m never going to fix those ones immediately … they need serious hammock time!

ChangeLog

• Fixed support for line numbers in classfiles (this required adding dead-code elimination phase at the WYIL level)
• Added a generic class for handling error messages.  The aim here is improve the quality and consistency of error message reporting, by providing a central class which is responsible for this.  However, this is in its infancy and a lot remains to be done here.
• Improved Compiler Documentation.
• Added support for parsing and checking throws clauses.  This require extending the function and method types to include another slot for the throws clause, which behaves much like that for return values.
• Added support for checking that catch handlers are not dead-code.  That is, every catch handler must be able to catch something in the try-catch block.
• Added support for the native modifier on functions/methods.  This indicates that the given method is implemented as a native Java method.  Under-the-hood, such methods are redirected into a class of the same package and name (but with “$native” appended to the name).
• Added support for the export modifier on functions/methods.  This tells the compiler that the function or method in question is intended to be called by some external (i.e. native Java) code.  Thus, the compiler omits the usual name mangling it would apply.
• Added support for passing modifiers (including native and public) through into the WYIL (which was surprisingly absent).
• Changed the way cases of a switch statement work.  Now, you can no longer “fall-through by default“.
• Removed the implicit coercion from char to int, which really didn’t make sense. You can still force this coercion using an explicit cast.
• Added some more methods to the core standard library.
• Added support for testing the length of a dictionary.
• Added do – while statement.
• Fixed a lot of bugs!

Future Work

• Fix the problem with type difference, where currently [int] - [int] => [void]
• Back propagation doesn’t work properly for try-catch blocks
• Back propagation doesn’t work through pre-/post-conditions and loop invariants.
• Many of the type constraints are not expanded properly.
• Include support for e.g. effective list types, etc.
• There is currently no way to determine if when a dictionary contains a particular key.

At some point though, you know it’s time.  You made a bad call, and you need to undo that and get back on track. It seems there are few different way to end up in this situation:

1. The Obvious Disaster. Perhaps this is the most common case.  You have an idea and start pushing it through.  But, after a while, it becomes obvious it will never work.  If you’d thought a bit harder up front, you’d probably have realised this.  Normally, not too much time is wasted.
2. The Winding Road. This one is ugly.  You’ve had an idea which, unbeknown to you, is fatally flawed.  The unfortunate thing is that the reason behind the flaw is very, very subtle.  It’s only after a fairly significant amount of effort that you (finally) realise: this approach can’t work.  This costs serious time, and is fustrating at best.  For me, I try not to lose to much sleep over these ones — they come with the territory.
3. The Good Idea. This one is even uglier!  You’ve had an idea which will actually work.  The problem is, it’s going to take a significant amount of effort to push through.  Furthermore, the gains from the improvement maybe somewhat marginal.  You’re completely paralysed: undo the work so far and waste what is a good idea simply because it’s going to take weeks or months to finish; OR, stubbornly keep going and push the damn thing through anyway.  I hate these ones, since I don’t like knowly going backwards.  These ones I lose lots of sleep over.
4. The Ping Pong.   This is where you revert, and then realise actually maybe you should have stuck with it.  So you undo the revert!  Then, maybe, you realise why you reverted in the first place and revert again, and so on.  I think experience makes you aware of this cycle, and helps you avoid it by forcing you to think carefully before reverting.

So, the question right now as I stare at my code is: what kind of revert are you?

Some more information about the awarded grants is available here as well.

The other main difference is the way in which import statements are handled. Whilst this is definitely a step in the right direction, it’s not without some outstanding issues — which I discussed in more detail here.

ChangeLog

• Changed the way imports are interpreted.  Previously, import whiley.lang.String would have imported all symbols from module String.  Now, it only imports the module name.  So, for example, to access the method indexOf, you need to write String.indexOf(s,i). However, you can still replicate the old approach by directly importing the names from a module. For example, import * from whiley.lang.String imports all names from the String module
• The entry point main() no longer has System as its receiver.  Instead, System is a parameter and main is a headless method.  This is necessary as, otherwise, the System process is blocked until main completes!
• Split out the type system into a separate library called wyautl.  As part of this, I’ve essentially reimplemented the type system from scratch in an effort to really harden it up.  I’ve done a significant amount of testing, and it’s definitely a lot better.  The type system now directly supports negation and intersection types, which makes for some interesting possibilities.
• Support for dictionaries is somewhat improved.  In particular, you can now create an empty dictionary!  An empty dictionary is denoted {->} (contrasting with {} for sets and [] for lists).
• Support for try-catch blocks has been added (finally).  This means you can now catch exceptions in Whiley.  At the moment, however, the system does not check that you properly declare your exceptions … but that will come shortly.
• Improved the JavaDoc documentation for the compiler.  I plan to make this documentation visible soon, in conjunction with detailed discussion of how the compiler actually works.
• Various bug fixes.

Tree Automata

A tree automaton in WYAUTL is a directed graph where edges may have labels.  In general, the nodes of this graph are called states, whilst the edges are called transitions.  States have the following properties:

• Kind.  Every state has a “kind”, which tells us something about it.  States with the same kind are somehow related and should be treated in the same way.  In Whiley, each distinct category of type has its own kind.  For example, void, any and null are distinct kinds.
• Children. Every state has zero or more children.  Essentially, the children of a state are those states directly reachable in a single transition.
• Determinism. Every state is either deterministic or non-deterministic.  This choice affects the way states are treated within the various algorithms.  Essentially, in a non-deterministic state, there is no fixed ordering of children.  In a deterministic state, every child is in a fixed position and can only accepts inputs in that position (more on this later).
• Supplementary Data. A state may additionally have some supplementary data.  This is specific to the problem domain the automata are used for.  In Whiley, for example, states corresponding to records have supplementary data to store field names.

A tree automaton accepts matching input trees.  An input tree is essentially an acyclic automaton (generally speaking a tree, although it doesn’t actually need to be).   Tree states have kinds, children and (optionally) supplementary data.  However, tree states are always deterministic.  The intuition is that an automaton state matches a tree state if they have the same kind, and their children match as well.  The issue of determinism and supplementary data make this picture slightly more complicated, however.

Example

To begin with, I’ll consider an entirely abstract example.  This is because the automata library can represent arbitrary tree automata, not just those needed to for types in Whiley.  Then, we’ll see how this translates into the underlying representation of types in Whiley.

In this example, we have a single automaton on the left, and three matching tree inputs on the right.  In the automaton, square nodes indicate deterministic states, whilst circles indicate non-deterministic states.  The kind of a state is given by its colour.  We can see, for the deterministic states, that every transition is given a numeric label.  This indicates the “position” of that transition and, for simplicity, can be thought of as an edge label.  In the tree inputs, every node is deterministic and, hence, all transitions are labelled.

In the above example, a deterministic state in the automaton matches a state in an input tree if they have the same kind, and each child matches the corresponding child in the input.  For the non-deterministic states, however, it’s sufficient that, for every child state of the input, there exists a matching child state in the automaton.

Back to Types

Types in Whiley are represented using tree automata.  In fact, if you look at my previous posts on the algorithmic aspects of implementing types in Whiley  (see e.g. here, here and here) you’ll notice a striking resemblance with the above diagrams.  That’s because, well, they’re essentially the same.  Take, for example, the following Whiley type:

define Tree as null | {int data, Tree left, Tree right}

The above type can be represented as a tree automaton, like so:

Here, grey states represent null, yellow states represent int, blue states represent records (i.e. { ... }) and green states unions (i.e. ... | ...). Furthermore, the rules for accepting inputs are adjusted so non-determinstic states do not themselves need to match a corresponding state in the input (although their children still do). The latter is made possible in the library because one can extend the “default interpretation” of automata.

Conclusion

Overall, implementing a general purpose automata library has proved successful in reducing complexity of the Whiley compiler.  This is because the library abstracts many of the key differences between types, and handles various issues such as minimisation and canonicalisation automatically. The library can also be developed and tested in isolation, making it easier to focus on without getting distracted by Whiley specifics.

define Queue as process { [int] items }

int Queue::get():
    item = this.items[0]
    this.items = this.items[1..]
    return item

void Queue::put(int item):
    this.items = this.items + [item]

Queue ::Queue():
    // following line should be invalid
    return spawn { items: [] }

The problem is that this code should not compile.  More specifically, the constructor ::Queue should generate a syntax error.

The reason for this is that we cannot safely subtype processes.  To see why, consider the following (artificial) example:

define MyProc as process { [int] field }
define BrokenProc as process { [int]|int field }

BrokenProc ident(MyProc mp):
    return mp // should not be allowed

void ::breakIt(MyProc mp):
    bp = ident(mp)
    bp.field = 1 // uh oh

[int] ::broken(MyProc mp):
    breakIt(mp)
    return mp.field // should be ok, but isn't...

The problem here arises from aliasing.  That is, since both mp and bp refer to the same process and, hence, assigning to bp.field corrupts the type of mp.field. To resolve the above problem we require that MyProc is not a subtype of BrokenProc.  In other words, no subtyping between process types should allowed.

This issue may seem fairly innocuous since we easily can “fix” it by preventing subtyping between processes.  Unfortunately, does this means spawn {field: []} is not a subtype of MyProc either, since it has type process {[void] field}. In other words, we cannot initialise a process field with an empty list!  There are some well-known ways in which we might get around this.  In particular, if we have a unique reference to a process, then subtyping is safe.  Looking at the ::Queue constructor again, we actually do have a unique reference since we just spawned it!