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 :-)
