So, I thought of a few . . . → Read More: Three Rules for Programming Language Syntax?]]> I’m always pondering the question: what makes good programming language syntax? One thing occuring to me is that many languages often ignore the HCI aspect.  For me, it’s a given that the purpose of a programming language is to simplify the programmer’s life, not the other way around.

So, I thought of a few simple rules:

1. Syntax should explain. The purpose of syntax is to help explain a program to a human.  In particular, structure in the program should be made explicit through syntax.
2. Syntax should be concise. The converse to (1) is that syntax should always add to the explanation.  Syntax which does not add value simply obscures the explanation.
3. Syntax should conform. The are many things people learn from everyday life, and we should not force them to unlearn these things.  Doing so can confuse the explanation, especially for non-experts.

I’m sure there are plenty of others you can think of.  I pick on these because I see them being broken constantly.  Let’s illustrate with some of my pet peeves:

Colons in Type Declarations?

There are plenty of programming languages which use colons in type declarations (ML is a classic example).  It goes something like this:

fun f (0 : int) : int = ...

For me, this breaks rule (2) because those colons do not add value.  The C-family of languages is evidence that we can happily live without them.  That’s not to say that C-like declaration syntax is the “one true way”; only that it demonstrates we don’t need those colons!

Function Call Braces: To Be or Not To Be?

Some programming languages require braces around the arguments to a function call, whilst others (e.g. Haskell) don’t.  Consider this:

(f (g h) 1 2) y 3

What can you tell about the invocation structure from this line?  Not much, unless you happen to know from memory exactly what arguments each function takes. This violates rule (3) since functions are normally expressed with braces in mathematics.

Now, how about this:

f(g(h),1,2)(y,3)

Personally, I prefer this style.  However, it would be fair to say that it violates rule (2) since the comma’s are not strictly necessary.  I suppose, in fact, we have a contradiction between (2) and (3) in this case, since commas are generally used to deliniate lists in written English.

Why Don’t we Teach Polish Notation at School?

(answer: because we don’t)

Some programming languages require mathematical expressions be expressed in Polish notation (a.k.a. prefix notation).  For example, in Lisp, we write (+ 1 2) to mean 1+2. This violates rule (3), since most people have learned mathematics at school where the usual convention applies.

Similarly in SmallTalk, the expression 2+3*4 is equivalent to (2+3)*4 rather than 2+(3*4), as might be expected.  Again, this violates rule (3) and is particularly insidious because it’s rather subtle.

The point here is not to say that e.g. one notation is fundamentally better than the other.  Just that, we learn one in school, so we should stick with that.

Conclusion

Well, if you made it this far, great!  Hopefully there was some food for thought, and maybe you can suggest some other examples…

I’ve just finished reading this book, which I have to say was really good.  The book is about how a handful of rogue scientists deliberately spread disinformation on a range of key issues, including tobacco, acid rain, the ozone hole and climate change.  Their key strategy was to argue the science . . . → Read More: Merchants of Doubt]]>

I’ve just finished reading this book, which I have to say was really good.  The book is about how a handful of rogue scientists deliberately spread disinformation on a range of key issues, including tobacco, acid rain, the ozone hole and climate change.  Their key strategy was to argue the science was inconclusive (even when it really wasn’t), that the scientists involved had some ulterior motive and, of course, to make such claims without evidence.  I found the stories both disturbing and eye-opening, especially with the underhand tactics being employed.  The key protaganists are Fred Singer, Frederick Seitz, William Nierenberg, and many others.  These people have a lot to answer for.

Perhaps the most interesting question is: why? Why do former scientists (who made good contributions in their field) go on the warpath to undermine science itself?  As a scientist myself, it seems unbelievable.  However, I think the book hits the nail on the head: they are free-market fundamentalists.  This view holds that the so-called Laissez faire (i.e. do nothing) approach to regulation is always the right approach.  Alan Greenspan is perhaps the most notable free-market fundamentalist of recent times … and look where that ended up!

Anyhow, definitely worth a read.

In Whiley, the syntax for switch statements currently . . . → Read More: Fall-Through by Default for Switch Statements?]]> The switch statement has a long history, and most languages support it or something similar.  In my experience, I found it to be very useful — both for conciseness, and also improving performance.  With the recent release of Java 7, you can finally switch over strings.

In Whiley, the syntax for switch statements currently looks like this:

for token in modifiers:
    modifier = null
    switch token.id:
       case "PUBLIC":
       case "public":
          modifier = ACC_PUBLIC
          break
       case "FINAL":
       case "final":
          modifier = ACC_FINAL
          break
       ...
       default:
          throw SyntaxError("invalid modifier",token)

(This excerpt is based on my Java Assembler/Disassembler benchmark)

Now, I’m having something of a dilemma over this syntax: should I support fall-through case statements or not?

As you can see from above, my initial reaction was: yes.  But, I’m starting to think this is a really bad idea and there are a few reasons:

1. Obviously, fall-through by default is dangerous as its easy to forget the break. I’ve already done this a few times!
2. Generally, I think fall-through is the exception, not the rule.  That is,  most cases do require the break and, hence, fall-through by default causes additional verbosity.
3. The overloaded break statement can be annoying when you actually want to break out of a loop.

Now, of course, I’m not the first to think along these lines (see e.g. [1][2][3]) and, in fact, I’m probably being a bit slow on the uptake here!

Several languages (e.g. Go, CoffeeScript, Pascal) do not support fall-through by default. For example, Go supports an explicit fallthrough statement, which might look something like this in Whiley:

for token in modifiers:
    modifier = null
    switch token.id:
       case "PUBLIC":
          fallthrough
       case "public":
          modifier = ACC_PUBLIC
       case "FINAL":
          fallthrough
       case "final":
          modifier = ACC_FINAL
       ...
       default:
          throw SyntaxError("invalid modifier",token)

Go is quite interesting as it provides multi-match case statements as well, which might look like something like this in Whiley:

for token in modifiers:
    modifier = null
    switch token.id:
       case "PUBLIC","public":
          modifier = ACC_PUBLIC
       case "FINAL","final":
          modifier = ACC_FINAL
       ...
       default:
          throw SyntaxError("invalid modifier",token)

I really like this syntax (which I think is originally from Pascal). In Pascal, you can provide ranges as well which certainly makes sense.

So, all things considered, I’m convinced it is a mistake to support fall-through by default in Whiley.  Fortunately, it’s not too late for me to correct this!

The big question then is: do I support explicit fallthrough, multi-match cases or both?

Previously, the above code would compile . . . → Read More: Namespaces in Whiley]]> With the upcoming v0.3.10 release of Whiley, the way import statements are interpreted has changed in a fairly significant manner.  The primary purpose of this is to give better support for namespaces. The following illustrates what’s changed:

import whiley.lang.Math

bool check(int x, int y):
    return max(x,y) == x

Previously, the above code would compile with function max() being imported from whiley.lang.Math.  In other words, an import statement automatically imports all names from a given module.  However, this gives relatively little control over namespaces and quickly leads to namespace pollution.

Therefore, in the upcoming release of Whiley, the semantics of import statements has been brought more in line with Python.  Thus, the above would not compile as is.  Instead, we would need to write:

import whiley.lang.Math

bool check(int x, int y):
    return Math.max(x,y) == x

This all makes sense, and I’m absolutely happy with the choice to do this.  However, as usual, there are some hidden issues I didn’t foresee.

Root Concepts

The first issue with the above change came out from actually writing code using it!  In particular, I was working on my bytecode disassembler benchmark and constructed a module ClassFile as follows:

define ClassFile as ...
define Reader as ...
define Writer as ...

This gives rise to the types ClassFile.Reader and ClassFile.Writer, both of which make sense. But, it also gives rise to the type ClassFile.ClassFile, which frankly is rather cumbersome. That’s because a ClassFile is both a key concept in my design and, coincidently, a namespace as well. Of course, I could prossibly rename ClassFile to be module Class as follows:

define File as ...
define Reader as ...
define Writer as ...

This gives rise to the types Class.Reader, Class.Writer and Class.File. This is better, but I suspect such renaming won’t always fit well with the top-level design of a program. I imagine Python must suffer from this problem as well, so I’ll have to look into it more …

Processes and Messages

Another problem with the above change to import statements, is how it affects process messages.  The following illustrates:

import whiley.io.File

[byte] ::readFile(String filename):
    fr = File.Reader(filename)
    return fr.read()

This all looks fairly sensible, right?  Well, currently, it doesn’t compile.  The reason becomes apparent if we look inside the File module:

package whiley.io

define Reader as process { ... }

Reader ::Reader(String filename):
    return spawn { ... }

[byte] Reader::read():
     ...

What we see is that read() is a message declared on process type File.Reader. In Java terms, read() is a static method which accepts an argument of type File.Reader. And, therein lies the problem. To get our readFile() example to compile we need to write this:

import whiley.io.File

[byte] ::readFile(String filename):
    fr = File.Reader(filename)
    return fr.(File.read)()

Or, alternatively, we could write it as this:

import whiley.io.File
import read from whiley.io.File

[byte] ::readFile(String filename):
    fr = File.Reader(filename)
    return fr.read()

I find this somewhat annoying.  However, it’s not clear how much of a problem it really is.  That’s because, in practice, we’d probably want to define File.Reader as an interface like so:

package whiley.io

define Reader as interface { [byte] read() }

Reader ::Reader(String filename):
    proc = spawn { ... }
    return { this: proc, read: &read }

[byte] Reader::read():
     ...

An interface is a special kind of record with an explicit field this. Then, when we access the field read, this is automatically used as the receiver. With Reader implemented as above, our original incantation of readFile() would actually compile. That’s because, in this case, fr.read() corresponds to an indirect message send, where as before it was a direct message send.

On the whole, I’m not sure what I’m complaining about! Implementing Reader as an interface versus a process is much of a muchness. There is a minor issue of performance as, for a process you get a static method invocation. But, I’m probably just splitting hairs …

In thinking about how to restructure the algorithms I’m using, I realised its important to distinguish simplification from minimisation.  I’ve talked about minimisation . . . → Read More: Simplification vs Minimisation of Types in Whiley]]> Recently, I’ve been trying to harden up the implementation of Whiley’s type system. The reason for this is fairly straightforward: bugs in the code often prevent me from compiling correct programs!

In thinking about how to restructure the algorithms I’m using, I realised its important to distinguish simplification from minimisation.  I’ve talked about minimisation in some detail before (see here and here).

In fact, there are three phases in computing the ideal representation of a given type (in order of increasing difficulty):

• Simplification. Here, we apply mostly straightforward simplifications.  Examples include: (T|T) => T, (T|any) => any, (T|void) => T, (T|(S|U)) => (T|S|U), etc.

• Minimisation. Here, we ensure that no two nodes in the type graph are equivalent under the subtyping operator.  For example, the type X<[null|[null|X]]> is not minimised, whilst X<[null|X]> is its minimised form.

• Canonicalisation. The final step is to ensure equivalent types have an identical representation on the machine.  This is related to the Graph isomorphism problem and, more specifically, the issues of computing a canonical form of a graph.

This all seems fairly straightforward … but there are of course some tricky bits!!

Simplification is not that Simple!

The first mistake I made was to assume that simplification was a simple step in the process.  Unfortunately, there are some gotchas:

define LinkedList as null | { LinkedList next, int data }
define MyList as int | LinkedList

The problem is how to minimise this.  One property I want of the simplified form is to eliminate unions of unions.  But, consider the type graph for MyList:

(here, circles represent unions, squares represent records, etc)

Now, it’s difficult to see how we simplify the above to remove the union (node 0) of a union (node 2).  That’s because of the recursive link directly into node 2.  In fact, we can achieve this by judiciously expanding the type like so:

This does the trick and (I believe) it’s always possible to eliminate unions of unions in this way.

Simplification Helps Minimisation!

You might be wondering: why bother with simplification at all? Well, it’s because it simplifies the minimisation algorithm (which is one of the components that features a lot of bugs).  In essence, simplification gives me the following property:

Property 1.  Any two equivalent nodes in a simplified type have identical reachable structure.

In a non-simplified type graph, the above is clearly not true.  For example, in the type (any|int) the outer union and any are equivalent (but have different structure). Here’s another example:

Here, nodes 0, 1 and 2 are all equivalent.  But, whilst nodes 1 and 2 have identical reachable structure, this differs from node 0.  In particular, the children of node 0 are in the same equivalence class as node 0, whilst those for nodes 1 and 2 are not.  In practical terms, my minimisation algorithm would have to handle this edge case and its numerous variations.  With simplified form, however, these awkward cases disappear.

Minimised is Simplified?

An interesting question is whether a type remains in simplified form after minimisation.  I conjecture that the answer is yes!  Atleast, provided a little care is taken.

The main issue is that the minimisation process can remove union nodes; however, it cannot introduce them.  Consider this final example:

define LinkedList as null | { LinkedList next, int data }
define InnerList as null | { OuterList next, int data }
define OuterList as null | { InnerList next, int data }
define MyList as LinkedList | OuterList

These definitions give rise to the following type graph for MyList:

This type graph is fully simplified (it’s a bit of a monster though!). This is because simplification does not attempt to eliminate equivalent nodes from a union, only identical ones.  After minimisation, the outermost union will be removed and we’ll be left with just this:

Now, back to the original issue.  In the general case, we can remove a union node from between any two nodes.  However, we cannot remove other kinds of nodes unless the entire subtree below that node is removed.  Therefore, we cannot introduce a union of union through this process.

I’ve . . . → Read More: Whiley v0.3.9 Released!]]> So, it’s that time again for another update of the Whiley compiler. Perhaps the most interesting update is that constraints are back! Admitedly, only runtime checking of constraints is back; and, there are quite a few problems with it. But, it’s a step in the right direction, and I’m pretty excited about it.

I’ve also been doing some more work on the benchmark suite. In particular, the Java Bytecode disassembler is coming along. One problem I’ve encountered, unfortunately, is that my type system implementation remains quite fragile. I will need to harden this up before the next release, otherwise I’ll never get the disassembler working …

Performance

Aside from large benchmarks (e.g. Chess and the Disassembler), I’ve also been adding micro benchmarks (both sequential and concurrent). For the sequential ones, I’ve provided a Java implemetation as well for comparison purposes. I thought it would be interesting to see how Whiley compares, so here we go:

Note the log scale. As expected, performance is truly woeful. However, it provides a useful start point for improving performance …

Wyclipse

Another interesting development, is that I’ve begun the process of constructing an Eclipse plugin. Things are pretty rudimentary at the moment, but I was able to get an editor with syntax highlighting working quite easily! You can see the code over on GitHub.

ChangeLog

• Added support for “headless” methods. A headless method is a method which has side-effects but has no explicit receiver. Such methods are useful, for example, for implementing constructors.
• Added ability to iterate strings and dictionaries.
• Changed semantics for dictionaries to support updating of keys.
• Put back in support for runtime constraint checking. The main outstanding issue here is that loop invariants don’t work.
• Turned off constant propagation because it’s causing lots of problems in relation to the constraints.

To implement the parallel sum, I divide the . . . → Read More: Parallel Sum in Whiley]]> Recently, I’ve been working on a variety of sequential and concurrent micro benchmarks for testing Whiley’s performance.  An interesting and relatively simple example, is the parallel sum.  The idea is to sum a large list of integers whilst performing as much work as possible in parallel.

To implement the parallel sum, I divide the list into roughly equal sized chunks and assign one process to each:

define Sum as process {
    [int] items,
    int start,
    int end,
    int result
}

void Sum::start():
    sum = 0
    for i in start..end:
        sum = sum + items[i]
    this.result = sum

int Sum::get():
    return result

// Sum constructor
Sum ::Sum([int] is, int s, int e):
    return spawn {
        items: i,
        start: s,
        end: e,
        result: 0
    }

Essentially, each Sum process holds the original list of items and a range start..end over which to operate. The result is used to store the final sum until it is requested by the outer loop.  The idea is that we first construct the processes, then start them all asynchronously and, finally, collect up the results.

The outer loop looks something like this:

define N as 100 // block size to use

int ::parSum([int] items):
    while |items| != 1:
        // Calculate how many workers required
        nworkers = max(1,|items| / N)
        size = |items| / nworkers
        // Construct and start workers
        pos = 0
        workers = []
        for i in 0..nworkers:
            if i < (nworkers-1):
                worker = Sum(items,pos,pos+size)
            else:
                // Last worker picks up the slack
                worker = Sum(items,pos,|items|)
            // Start worker asynchronously
            worker!start()
            // Bookkeeping
            workers = workers + [worker]
            pos = pos + size
     // Collect up results
     items = []
     for i in 0 .. nworkers:
         items = items + [workers[i].get()]
 return items[0]

The key here is that the outer loop continues until the original list of items is reduced to a single result. There maybe several iterations required, depending on the block size. Furthermore, the block size determines how many items will be processed by each process in one go. Smaller block sizes lead to more parallelism, but have higher overheads. The optimal block size probably depends on the underlying architecture, and would ideally be chosen at runtime.

The main changes since . . . → Read More: Whiley v0.3.8 Released!]]> Now that teaching has started up again, development has slowed a little. This release is primarily a bug fix release. The benchmarks and examples now all compile again, which is great! I’ve also significantly increased the number of micro benchmarks, as I’m gear up for some performance testing …

ChangeLog

The main changes since v0.3.7 are:

• Added proper support for internal message sends.
• Reworked the JVM implementation behind coercions.
• Added support for detecting ambiguous coercions, and reporting a syntax error.
• Added support for an explicit cast operator, which follows C’s cast syntax.
• Fixed numerous bugs

The starting point is . . . → Read More: A Semantic Interpretation of Types in Whiley]]> An interesting and intuitive way of thinking about a type system is using a semantic interpretation.  Typically, a set-theoretic model is used where a type T is a subtype of S iff every element in the set described by T is in the set described by S.

The Semantic Model

The starting point is to define our notion of types T and values V:

• T ::= null | int | any | [T] | {T1 f1, ... Tn fn} | T1 ∨ T2

• V ::= null | i | [V1,...,Vn] | {f1: V1, ... f2: V2}

This is a simplified notion of the types and values found in Whiley.  For example, I’ve left out sets and function references and ignored recursive types altogether.

We can define our semantic model as follows using an acceptance relation T |= V, which holds if value V is in the set described by type T.

• null |= null
• any |= V
• int |= i, if i ∈ I (the set of all integers)
• [T] |= [V1,...Vn], if ∀1≤i≤n.[T |= Vi]
• {T1 f1, ..., Tn fn} |= {f1: V1, ... fn: Vn}, if T1 |= V1, … Tn |= Vn
• T1 ∨ T2 |= V, if T1 |= V or T2 |= V

Note: this model could be made more advanced by supporting width subtyping — but its enough for now.

Finally, we can give a semantic notion of subtyping where T1 |= T2 holds if ∀V.[T1 |= V implies T2 |= V]. In otherwords, T1 |= T2 if T1 is a subtype of T2.

The Subtyping Algorithm

Now that we have an “intuitive” model of what types should mean, we want to compare that against an actual algorithm for subtype testing. The following pseudo-code outlines the basic algorithm used in Whiley:

// Check whether t1 is a subtype of t2
bool isSubtype(Type t1, Type t2):
   // rule 1
   if t2 is any:
       return true
   // rule 2
   else if t1 == t2:
       return true
   // rule 3
   else if t1 is [t3] && t2 is [t4]:
       return isSubtype(t3,t4)
   // rule 4
   else if t1 is {t3 f3, ..., Tn fn} &&
            t2 is {s3 f3, ..., Sn fn}:
       for i in 3..n:
           if !isSubtype(ti,si):
               return false
       return true
   // rule 5
   else if t1 is (t3 ∨ t4):
       return isSubtype(t3,t2) && isSubtype(t4,t2)
   // rule 6
   else if t2 is (t3 ∨ t4):
       return isSubtype(t1,t3) || isSubtype(t1,t4)
   // rule 7
   else:
       return false

Thus, for example, isSubtype(int,any) holds under rule 1, whilst isSubtype(int,int ∨ null) holds by rules 6+2.

The Question

Soundness. If isSubtype(T1,T2) then T1 |= T2.

Completeness. If T1 |= T2 then isSubtype(T1,T2).

Considering these questions separately simplifies the problem.  I’m not going to provide any proofs, but it’s relatively easy to see that isSubtype() is sound.  The more interesting question is whether or not it is complete.

In fact, it turns out that the isSubtype() algorithm as given is not complete.  A simple counter-example is sufficient to show this.  Let T1 = {int ∨ null x} and T2 = {int x} ∨ {null x} .  Then, T1 |= T2, but isSubtype(T1,T2) does not hold. This is because rule 6 requires isSubtype(T1,{int x}) and isSubtype(T1,{null x}) (neither of which hold).

The problem is that isSubtype() is not distributive over records. An interesting question is how we can fix it, but that’s a story for another day!

If you’re interested in learning more about this, I’ve worked through the full system in this paper.  Also, the following reference provides a good introduction to semantic subtyping:

• “A Gentle Introduction to Semantic Subtyping”, Giuseppe Castagna and Alain Frisch. In Proceedings of the ACM Conference on Principles and practice of declarative programming (PPDP), 2005. [ACM Link][PDF]

Deciding upon the language syntax is obviously the highest priority . . . → Read More: The State of Whiley]]> The aim of this post is simply to list the main outstanding issues with the design and implementation of Whiley.  This is primarily for my own purposes, in order to help me focus my efforts and to ensure I don’t forget something important.

Syntax

Deciding upon the language syntax is obviously the highest priority for me right now.  Over the last six months, a lot of the syntax has been locked down.  However, there remains a number of issues (some of which are thorny).

• Message Send Syntax. Currently, the syntax for sending messages to actors is not finalised.  This post provides all of the interesting details.
• Implicit Coercions. These are causing me something of a headache as, in the context of structural subtyping, they’re quite tricky.  This post provides some insight into the problem, as does this post.
• Default Imports. Currently, like Java, every Whiley source file implicitly imports whiley.lang.* which (I think) is a bad idea. The reason for this is that it doesn’t make sense to unnecessarily clutter the namespace of every source file.  On the other hand, it is annoying to have to include that import explicitly, as most files will probably want it.
• Imports.  Currently, when you import a module, all names from that module are imported directly.  For example, suppose a module String contains a function indexOf(). The statement import String will import the name indexOf directly into our namespace. This is convenient, but opens up potential for name clashes. It might be better for import String to import the name String.indexOf rather than just indexOf (like Python).
• Encapsulation.  Currently, there is no real support for encapsulation modifiers (e.g. public, private, etc). I plan to support public and private in the obvious ways.  However, I also want a third option.  Consider the definition public define Rec as {int x}.  This makes the name and its contents visible to clients.  But, I also want to be able to export the name without its contents.  The two options I’m considering are: using protected for this to be used in place of public; or, providing a special export declaration.  The idea of the latter is that, for a private type, we can declare something like export Rec — this just makes the name Rec visible to clients, and nothing else.  I’m leaning towards protected as it’s simpler, but it would cause some confusion with the meaning of protected in other languages.
• Interface Syntax. Currently, there is no way to declare an interface, such as e.g. Reader in Java.  This is a serious deficiency which I will rectify as soon as I figure out the best way of doing it.
• Bindings. Currently, every function or method compiled to JVM Bytecode has its name mangled … which makes it impossible to call such functions/methods from native Java.  I am considering providing a “binding” modifier for methods/functions.  This would ensure a version of the method/function existed which was unmangled.
• Entry Point. Currently, the entry point for a Whiley program is void System::main([string] args).  This is problematic as it means that, until the main method exits, no actor can send a message to the System process.  One option is to support “headless” methods in Whiley — then, the signature would become e.g. void ::main(System sys, [string] args).  In fact, the command-line arguments could be held in sys to further simplify this.
• Currying. Currently, you can take the address of a function (e.g. &f).  However, you cannot curry functions.  So, I’d like to support syntax such as e.g. &f(2,_), where the underscore indicates the actual parameter.
• Actor Fields. Currently, you do not need to provide this when reading a field from this actor (unless a local variable of the same name already exists).  However, when assigning fields you do need to provide this (this post discusses why)  Likewise, you currently need to provide this when making an internal message send (however, I could infer it in most cases).  I’m wondering whether or not requiring this in all cases would be more a uniform approach, and give better readability.
• String Conversions.  Currently, the system does not implicitly convert data types into strings.  Instead, you must explicitly call str().  For example, to print an integer i, you would write out.println(str(i)).  This seems a little cumbersome, and somewhat unnecessary.

Implementation

The current implementation targets the Java Virtual Machine and, for the most part, is in good shape.  However, there are a number of outstanding issues.

• Type System.  My work on formalising Whiley’s type system has thrown up a number of interesting issues.  In particular: types are not currently represented in a canonical fashion; they do not support distributivity across records/function types; and, ideally, they would include intersection and negation as first-class components.
• Dictionary and String Iteration.  You cannot at the moment iterate over dictionaries or strings using the for loop.  This is a minor issue to fix.
• Break/Continue Statements.  Break and continue statements are only semi-working right now.  Again, only a minor issue.
• Exceptions.  At the moment you can throw exceptions, but you cannot catch them!  This should be easy to fix.  I need to consider whether or not a finally block is required.
• Actors.  At the moment, Actors are currently implemented using a single Thread per actor.  This is highly inefficient, and eventually we will support green threads.
• Native function/method declarations.  I will provide a native modifier for functions/methods to indicate they are provided by the system.
• Whiley Bytecode File Format.  There is no binary file format for wyil files.  Thus, all signature information is currently stored directly in the Java classfile.  Eventually, however, such information will be stored in a binary wyil file (similar, in some ways, to a header file in C).  Then, the WHILEYPATH will only be searched for wyil files, not Java classfiles.  The primary reason for this is to support compilation to non-JVM targets, such as machine code.
• Record Access Bytecodes. Currently a record access requires a specific type (i.e. Type.Record) which is generated from effectiveRecordType().  This is a problem as the back-end loses knowledge of the actual representation of types.  For example, {int x}|{[int] x} is converted by effectiveRecordType() into {int|[int] x} to be stored in a FieldAccess bytecode.  This presents a problem if {int x} is represented differently from {int|[int] x} (which it might be in the case of int being implemented using a native int).

And, of course, there are quite a few outstanding bugs yet to be fixed!

Performance

Performance is a significant issue in Whiley at the moment.  It’s unlikely that this will change in the near future, however eventually I will address it.  There are currently three main techniques that I will use to address this:

• Reference Counting.  Here, the idea is that every compound structure (e.g. a list) maintains a reference count.  Then, when an update is made to a compound structure, the count is checked.  If its > 1 the structure is cloned; otherwise, the update occurs in place. See this paper for more on how this might work.
• Integer Range Analysis.  A significant challenge in Whiley (from a performance perspective) is that the int type represents unbounded integers which are currently implemented as a BigInteger. However, when possible, we want to use native JVM ints. In order to do this, I propose using an integer range analysis to determine the lower and upper bounds of a given type. This would be performed intra-procedurally and, in conjunction with pre/post-conditions, it should be very effective.  See this link for relevant papers.
• Native Lists/Sets.  Currently, lists of e.g. bytes are implemented as e.g. ArrayList<Byte>. This is not efficient and I want to provide specific list implementations which (in this case) would use byte[] internally.
• Representation of Records. Currently records are represented by HashMap.  However, it would be more efficient to represent them as Object[], giving guaranteed constant-time lookup.
• Tagged Unions.  In some cases, a tagged union could speed up runtime type tests.

I believe the above should compile without error.  However, this requires an implicit coercion . . . → Read More: Implicit Coercions in Whiley]]> The issue of implicit coercions in Whiley is proving to be a particularly thorny issue.  The following motivates why (I think) coercions make sense:

real f(int x, real y):
    return x + y

real g(int x, int y):
    return f(x,y)

I believe the above should compile without error.  However, this requires an implicit coercion from int to real in several places.  Some statically typed programming languages (notably ML) simply don’t perform any implicit coercions.  Instead, they require explicit coercions in the form of type casts.  Under this model, the above code would be:

real f(int x, real y):
    return real(x) + y

real g(int x, int y):
    return f(x,real(y))

To me, this seems rather cumbersom and, when it’s clear from the context, I want the compiler to do this for me.

So, what coercions could we support in Whiley?  Here’s a taster:

• int –> real
• {int x, int y} –> {int y}
• [int] –> {int}
• {int->int} –> {int,int}
• [string] –> {int->string}

Unfortunately, whilst this looks all good on the surface, there are some tricky cases.  Here’s one example:

define Rec1 as { int x, real y }
define Rec2 as { real x, int y }
define Rec12 as Rec1 | Rec2

int f(Rec12 r):
   if r is Rec1:
       return r.x
   else:
       return r.y

int test():
   z = {x: 1, y: 1} // z has type {int x, int y}
   return f(z)

The problem here is that we cannot determine whether to coerce z to Rec1 or Rec2.  I guess we should report an ambiguous coercion error. Which immediately raises the question of how, in the general case, I detect this.

The talk is by Greg Young and focuses on .Net’s contracts library.  It’s quite interesting, and you can see the contracts in action.  From my perspective, what’s very interesting is that he shows . . . → Read More: Compile-time Verification, It’s Not Just for Type Safety Any More]]> I just came across an interesting presentation over at InfoQ called “Compile-time Verification, It’s Not Just for Type Safety Any More“:

The talk is by Greg Young and focuses on .Net’s contracts library.  It’s quite interesting, and you can see the contracts in action.  From my perspective, what’s very interesting is that he shows compile-time checking of contracts …

A nice example of a regular tree language . . . → Read More: Regular Tree Automata]]> In my quest to understand the theory of recursive types in more detail, the notion of regular tree languages and Tree Automata has cropped up.  These have been used, amongst other things, for describing XML schemas.  They are also useful for describing recursive types as well!

A nice example of a regular tree language is one for minimising boolean expressions.  The  constructors of the language are True, False, Not/1, And/2 and Or/2. The regular tree language looks thus:

Expr -> True
     | False
     | Not(Expr)
     | And(Expr,Expr)

This should look pretty familiar to anyone who’s studied context-free and/or regular languages before.  A simple (deterministic) bottom-up tree automata can then be defined using the following state transitions:

True --> q1            Not(q0) --> q1
False --> q0           Not(q1) --> q0
And(q0,q0) --> q0      And(q1,q0) --> q0
And(q0,q1) --> q0      And(q1,q1) --> q1

I guess the interesting question is how this differs from general regular languages.  They appear to be very similar — for example, they support minimisation, intersection and union (amongst other things).  Likewise, the relationship with context-free grammar is interesting … although I haven’t got to the bottom of that yet.

Anyway, a good reference on this subject is the book Tree Automata Techniques and Applications.

Therefore, in Whiley, a byte is just that: a bit . . . → Read More: Bits, Bytes and More Ambiguous Syntax]]> Recently, I added a first-class byte type to Whiley.  Unlike Java, this is not interpreted as some kind of signed or unsigned int. That’s because I find that very confusing since a byte is really just a sequence of bits without any interpretation.

Therefore, in Whiley, a byte is just that: a bit sequence on which you can perform the usual operations, such as bitwise AND/OR/XOR operations, as well as left and right shifts. Here’s a snipper which accepts a byte and converts it into an unsigned int assuming a little endian representation:

int le2uint(byte b):
    r = 0
    base = 1
    while b != 0b:
        if (b & 00000001b) == 00000001b:
            r = r + base
        b = b >> 1
        base = base * 2
    return r

As usual, updating the compiler to support the byte type did not go according to plan. That’s because I ran into yet another ambiguity of syntax. This time the ambiguity is surrounding the | operator, which represents bitwise OR and is also a delineator for set comprehensions. Consider these three examples:

x = b1 | b2    // bitwise OR
y = { a | a in as,  a > 0 }    // comprehension
z = { a | a in ys }    // hmmmm, set generator or comprehension?

In fact, it’s fairly easy to disambiguate the last statement — it must be a set comprehension. That’s because a in ys has bool type, and this cannot be part of a bitwise OR operation. However, at the point it needs to make this decision, the compiler doesn’t have access to type information. This is because type propagation occurs after the source has been translated into the intermediate language (wyil). But, there is no bytecode in the Wyil for a comprehension and, instead, it is constructed using for loops).

I believe it is possible to disambiguate bitwise OR from a set comprehension in the parser — however, for the moment, I just resolve it by preferring set comprehensions over bitwise OR. The impact of this is that the expression { a|b } won’t parse because it’s not a valid set comprehension (but is a valid set generator). Instead, you have to help the parser using braces. So, { a|b } becomes { (a|b) }.

Finally, whilst I’d love to say “go and use this . . . → Read More: Whiley v0.3.6 Released!]]> After an untold number of commits, bug fixes and passing unit tests, the next version of Whiley is released!!  I am trying to lock down the syntax of the language as much as possible now, although there are still a number of open issues.

Finally, whilst I’d love to say “go and use this version” … frankly, you probably shouldn’t!  There remain quite a few problems, and the benchmark suite doesn’t even compile.  The switch to using the new bytecode-oriented intermediate language (wyil) was very significant, and it’ll take a little while to settle down.  Hopefully, the next release will be much sooner …

ChangeLog

• Changed the Whiley Intermediate Language (Wyil) to be a proper bytecode format.  This simplifies many things, and enables easy implementations of interpreters and virtual machines.
• Changed syntax for synchronous and asynchronous message sends from <-> and <- to . and !
• Changed syntax for top type from * to any
• Changed syntax for type tests from ~= to is
• Added a first-class string type.  Currently, there is no char type — this may or may not get added eventually.  The reason for adding this type is to allow for better conversions from data types to strings.  In particular, I want strings to displayed as strings, rather than just lists of integers.
• Changed the underlying model of types from the “ideals” to the “reals”.  See this blog post for more.  As part of this, int values are now implemented as BigIntegers with real types being implemented as BigRationals.
• Implemented a simpler, but more complete mechanism for performing type tests.  This is probably slightly less efficient than before, because much of it takes place in the runtime library code rather than being hard-coded into JVM bytecode.
• Implemented a simpler approach to performing type coercions, which is based on the mechanism for type tests.  However, I’m not convinced it’s actually making things better.
• Put in place the basic mechanism for implementing reference counting of compound data structures.  At this stage, I don’t actually use reference counting … but that will come soon enough!

To Do Next

• Sort out the implicit coercions
• Implement complete code for coercions
• Add proper first-class tuples to wyil
• Fix up problems with function refs, and add support for method refs (and possibly interfaces)
• Add support for iterating dictionaries (kind of important)
• Fix the multistore bytecode so it’s a little less chaotic.
• Fix problems with fieldload, listload, dictload and effective “union” types
• Adjust wyil so strong correlation between bytecodes and program statements (probably requires explicit logical not, and, or and xor operators)
• Adjust wyil to support “named” types to make it a little more human readable (and hopefully to help with error messages as well).
• Fix up exceptions: 1) to check for the required throws clause; 2) to support try-catch blocks.