We've been spending time discussing the priorities for development of Ceylon 1.1.5 and 1.2, including soliciting community feedback. The plan is still suprisingly fluid right now, but there are a number of things that we've already started working on, or have decided to start working on, and so in the interest of transparency, I thought I would share them.

Warning: we're not committing to a timeframe or release version for most of these features. It's merely a summary of what we're working on now, or plan to start work on soon.

Serialization

As already announced, ceylon.language 1.1.5 will feature an API for Serialization. Note that this API does not itself specify a serialization format. Rather, it's a general-purpose and platform-neutral facility for marshalling objects to and from a serialized stream. Serialization libraries founded on this API may serialize to text-based formats like JSON or XML, to binary formats, or even to a database via ORM.

Work on this API is already well-advanced. Tom has already done the Java implementation, and Enrique has got it working in JavaScript.

Type argument inference for function references

In Ceylon 1.1, we made it possible to leave off the type of a parameter of an anonymous function that occurs in an argument list, letting the type be inferred by the compiler, for example:

{Float*} measurements = ... ;
Float product = measurements.fold(1.0)((x,y)=>x*y);

In Ceylon 1.1.5, I've extended this approach to cover references to generic functions. So now, instead of this:

{Float*} measurements = ... ;
Float product = measurements.fold(1.0)(times<Float>);

You can write this:

{Float*} measurements = ... ;
Float product = measurements.fold(1.0)(times);

This even works for static value references, so instead of this:

{[Float+]*} sequences = ... ;
{Float*} heads = sequences.map(Iterable<Float>.first);

You can write simply this:

{[Float+]*} sequences = ... ;
{Float*} heads = sequences.map(Iterable.first);

This is already implemented, and you can try it out in git. It will be released in Ceylon 1.1.5.

Named constructors

In Ceylon 1.1, there is only one "constructor" of a class, the body of the class itself. For the vast majority of classes this is far more elegant and convenient. But in a minority of cases, there is a true need to have multiple initialization paths, and so we've designed a new syntax to support that. It took us a while to come up with something elegant and regular that didn't break the block structure of the language or the rules about definite initialization, but I'm very happy with the final outcome.

Since Ceylon doesn't have overloading (except for Java interop), constructors have distinct names.

class Point {
    shared Float x;
    shared Float y;

    //the "default" constructor
    shared new Point(Float x, Float y) {
        this.x = x;
        this.y = y;
    }

    //an additional constructor
    shared new Diagonal(Float d) {
        x = (d^2/2)^0.5 * d.sign;
        y = x;
    }
}

Every constructor must initialize all members which are left uninitialized by the body of the class, and must delegate to a constructor of the superclass (in this case, they delegate to Basic() by default). Now we can create a Point in two different ways:

Point p1 = Point(2.0, 3.0);  //call the default constructor
Point p2 = Point.Diagonal(1.0);

The typechecker already supports constructors, and Tom has made good progress on implementing this feature for the Java backend. I'm not sure if this will make it into 1.1.5, but if it does then we might actually need to rename 1.1.5 to 1.2, given that this is a pretty significant enhancement to the language itself.

Extensions to the expression syntax

We're making several extensions to the expression syntax. These features are already supported in the typechecker, but not yet by the backends. Note that these features are especially useful when combined with certain other features of the language, like comprehensions, anonymous functions, named argument lists, and fat arrow function definitions.

Inline object expressions

An inline anonymous object expression is very similar to an anonymous class in Java, and is useful in essentially the same cases. For example:

printAll(object satisfies {Integer+} {
    iterator() =>
        object satisfies Iterator<Integer> {
            variable value current = 0;
            next() => current++;
        };
});

let expressions

A let expression allows the definition of new values within an expression. For example:

Float d = ... ;
value ptl = let (x = (d^2/2)^0.5 * d.sign) Point(x,x);

Inline if and switch expressions

Ceylon's then and else operators are nice, but they don't do anything special in terms of flow-sensitive typing, so we quite often run into cases where we're forced to use a whole if or switch statement in a block. To alleviate that minor source of discomfort, we're now going to let you use if and switch within expressions. For example:

String string(Object it)
        => if (is Person it) 
           then it.name 
           else it.string;

Or:

String name(Person|Org it)
        => switch (it) 
           case (is Org) it.tradingName 
           case (is Person) it.firstName + " " + it.lastName;

Cayla web framework

Frameworks for developing web applications are a top request from the community. After some discussion, we've decided to focus first on the server side, and come back later to the problem of client-side web frameworks. Note that there's no problem at all with using a native JS client-side web framework to call a Ceylon module compiled to JavaScript.

Julien is going to work on getting Cayla, a web framework for use on Vert.x, ready for release.

To showcase Cayla, Ceylon, and Vert.x, Julien is going to do a partial port of Ceylon Herd from Java/Play to Ceylon/Cayla. That should make for a great demo.

SDK modules ceylon.html and ceylon.promise

Cayla will offer a choice of templating technologies, but one of the options we obviously want to offer is templates written in Ceylon. In order to avoid the cost of rebuilding the template from scratch on each request, ceylon.html needs to be enhanced to support a mix of static nodes and nodes which are created or rendered dynamically.

Work on Cayla will also likely necessitate improvements to ceylon.promise, and, in particular, we need to make this module cross-platform (right now it is only available on the JVM).

Java EE integration

Toby Crawley has started work on integration with Java EE. The first order of business here is to make it easy to write a servlet in Ceylon and package it into a war archive. After that, we'll need to make sure Ceylon works well with CDI, JPA, JAX-RS, etc.

Improved debugging in Ceylon IDE

David is going to work on making Eclipse's debugger work better with Ceylon. This is now the only really major feature missing from Ceylon IDE, so when he's done with that, he's going to move onto the #1 requested feature from the Ceylon community, which is...

IntelliJ-based IDE for Ceylon

The IntelliJ plugin for Ceylon is still rudimentary, and not yet ready for release. But now that the Eclipse-based IDE is feature complete, we're going to refocus our tooling development efforts on IntelliJ.

Note that this doesn't really represent a change of direction for us; I'm an Eclipse user, I prefer Eclipse, and I see no good reason to change to IntelliJ. That's especially true since whenever I discover a nice feature of IntelliJ, I just go ahead and reimplement it in Ceylon IDE ;-) However, we recognize that there are plenty of folks on the other side of the fence, who, preferring IntelliJ, and likewise seeing no reason to change, deserve a great plugin for Ceylon. So I hereby promise that we will have absolutely awesome tooling for both these IDEs.

Source maps

To make it easy to debug Ceylon code running on a JavaScript virtual machine, Enrique is going to add support for source maps to ceylon compile-js.

Consume Typescript interface definitions

Microsoft's Typescript project (which recently took inspiration from Ceylon by adopting our approach to union types and flow sensitive typing) has put a whole lot of work into defining statically typed definitions of important APIs in the JavaScript world. Now that Ceylon 1.1 has dynamic interfaces it's at least in principle possible to have a well-defined transformation from a Typescript API definition to a Ceylon type. This could take the form of a mechanical source translator, or even a "model loader" for the Ceylon compiler. Stef is going to investigate this.

More

The above is an incomplete list. If the thing you're waiting for (Android!!) isn't on that list, that doesn't mean we don't want to work on it, it just means I don't yet have a concrete plan for actually starting work on it right now. Feel very welcome to bug us about it in comments or on the mailing list or IRC :-)