Ceylon M5 “Nesa Pong” is now available for download, along with a simultaneous compatible release of Ceylon IDE. This is a huge release, with the following headline features:

• a fully-reified type system with generic type arguments available at runtime,
• direct interoperation with native JavaScript,
• tuples,
• several important syntax changes in response to community feedback and practical experience, and
• a datetime module and an HTTP server.

You can download the Ceylon command line distribution here:

http://ceylon-lang.org/download

Or you can install Ceylon IDE from our Eclipse update site.

Language features

M5 is an almost-complete implementation of the Ceylon language, including the following new features compared to M4:

• tuples
• direct interop with native JavaScript APIs via the new dynamic block
• the : operator
• verbatim strings
• fat arrow => abbreviation for defining single-expression functions
• syntactic sugar for iterables
• more powerful spread operator
• the late annotation
• binary and hexadecimal numeric literals
• defaulted type parameters
• reified generics
• many miscellaneous minor improvements to the syntax and typing rules of the language
• ceylon.time module
• ceylon.net.http.server package (a HTTP server)
• the compose() and curry() functions
• reworked interop with Java arrays
• more than 500 features and bug fixes

In addition, the language specification and documentation have been substantially revised and improved.

The following language features are not yet supported in M5:

• the type safe metamodel
• user-defined annotations
• serialization

This page provides a quick introduction to the language. The draft language specification is the complete definition.

Source code

The source code for Ceylon, its specification, and its website, is freely available from GitHub:

https://github.com/ceylon

Issues

Bugs and suggestions may be reported in GitHub's issue tracker.

Community

The Ceylon community site includes documentation, the current draft of the language specification, the roadmap, and information about getting involved.

http://ceylon-lang.org

SDK

The new platform modules are available in the shared community repository, Ceylon Herd.

http://modules.ceylon-lang.org

Acknowledgement

We're deeply indebted to the community volunteers who contributed a substantial part of the current Ceylon codebase, working in their own spare time. The following people have contributed to this release:

Gavin King, Stéphane Épardaud, Tako Schotanus, Emmanuel Bernard, Tom Bentley, Aleš Justin, David Festal, Flavio Oliveri, Max Rydahl Andersen, Mladen Turk, James Cobb, Tomáš Hradec, Michael Brackx, Ross Tate, Ivo Kasiuk, Enrique Zamudio, Roland Tepp, Diego Coronel, Brent Douglas, Corbin Uselton, Loic Rouchon, Lukas Eder, Markus Rydh, Matej Lazar, Julien Ponge, Julien Viet, Pete Muir, Nicolas Leroux, Brett Cannon, Geoffrey De Smet, Guillaume Lours, Gunnar Morling, Jeff Parsons, Jesse Sightler, Oleg Kulikov, Raimund Klein, Sergej Koščejev, Chris Marshall, Simon Thum, Maia Kozheva, Shelby, Aslak Knutsen, Fabien Meurisse, Paco Soberón, sjur, Xavier Coulon.

One of the exciting new features coming to the Ceylon SDK in M5 is the HTTP server contributed by Matej Lazar. The HTTP server forms part of the module ceylon.net and is based on Undertow, a fairly new project that will serve up HTTP in future versions of JBoss.

The API is still evolving, but I can give you a taste of it with a little hello world program.

import ceylon.net.httpd { createServer, Endpoint, Response, Request }

void runServer() {
    //create a HTTP server
    value server = createServer {
        //an endpoint, on the path /hello
        Endpoint { 
            path = "/hello";
            //handle requests to this path
            service(Request request, Response response) =>
                    response.writeString("hello world");
        }
    };

    //start the server on port 8080
    server.start(8080);
}

Or, if you're the kind of person who gets their kicks out of squeezing things into one line:

import ceylon.net.httpd { createServer, Endpoint, Response, Request }

void runServer() => 
        createServer { Endpoint("/hello", 
                (Request request, Response response) =>
                        response.writeString("hello world")) }
        .start(8080);

(No, FTR, I would never write it like that.)

Oh, I almost forgot, you'll also need to import ceylon.net in your module descriptor:

module hellohttp '1' {
    import ceylon.net '0.5';
}

Of course, what you don't need is any kind of XML metadata or build script to package stuff up into deployment archives or copy archives to a deployment directory.

And it starts up in an instant, right from the commandline or IDE.

Thanks to a bunch of hard work by Stef, Ceylon finally has fully reified types, that is, reified generic type arguments. You can now write stuff like this very contrived example:

"Check if the given value is an instance 
 of the given type."
Boolean check<T>(Anything o) => o is T;

"A string is a list of characters."
assert (check<List<Character>>("hello"));

"A string is a list of objects."
assert (check<List<Object>>("hello"));

"A string isn't a list of integers nor a 
 list of floats."
assert (!check<List<Integer>|List<Float>>("hello"));

This long-promised feature, promised almost two years ago, will be available in the upcoming M5 release of the language. The truth is that it's going to take a fair bit more work to do all the optimizations we plan in order to wring acceptable performance out of this stuff, but we've got a couple of clever ideas in this area, that I'm going to keep under wraps for now. ;-)

So why is reified generics important? Well, I took a brief stab at answering that question way back when, but since then we've spotted a couple of other compelling reasons. So lets take a quick look at one practical problem that is extremely difficult to solve without reified generics.

Ceylon's language module has an interface called Category

shared interface Category {
    shared formal Boolean contains(Object element);
    ...
}

A Category is an object that can "contain" other objects. Given an object, we can ask if it belongs to the category by calling contains(), or using the in operator.

Of course, collections are Categorys:

shared interface Collection<out Element>
    satisfies {Element*} &
              Category & 
              ...

Now, notice that the signature of contains() for a Collection<String> is contains(Object element), not contains(Element element). The reason for that is that we want collections to be covariant in their element type. I should be able to write the following:

Collection<String> strings = [ "hello", "world" ];
Collection<Object> objects = strings;
print(1 in objects);

Notice that on the last line, an Integer gets passed to the contains() method of a Collection<String>.

So the, without making use of reified generics, the default implementation of contains() defined by Collection would be as follows:

shared actual default Boolean contains(Object element) {
    for (elem in this) {
        if (exists elem, elem==element) {
            return true;
        }
    }
    else {
        return false;
    }
}

That's already kinda lame. If I have a Collection<String>, and contains() gets passed an Integer, we should be able to immediately return false like this:

shared actual default Boolean contains(Object element) {
    if (is Element element) {
        for (elem in this) {
            if (exists elem, elem==element) {
                return true;
            }
        }
    }
    return false;
}

But, well, whatever, that's merely a minor performance optimization, I suppose. But now consider the case of a Range. A Range is a kind of Collection whose elements are determined by two endpoints, which could potentially have thousands or millions or even more values in between! The above default implementation of contains(), inherited from Collection, would be so hideously expensive as to be actually wrong. So Range should refine the implementation of contains() as follows:

shared actual Boolean contains(Object element) {
    if (is Element element) {
        return includes(element);
    }
    else {
        return false;
    }
}

shared Boolean includes(Element element) =>
        decreasing then element<=first && element>=last
                else element>=first && element<=last;

The is Element element test requires reified generics. Without it, I can't be sure that the given value is a Comparable<Element>, so I can't compare the given value to the endpoints of the Range.

What I've shown here, for those interested in type systems, is that in a type system with declaration-site covariance, there are perfectly legitimate reasons to want to be able to test the runtime type of a value. Sure, ML and Haskell don't need to do this kind of thing, but those languages don't feature subtyping, and therefore don't have covariance. Object oriented languages are very different, so please take that into account before arguing that reified generics are unnecessary.

UPDATE: For more information about the implementation, see Stef's email here:

https://groups.google.com/forum/?hl=en&fromgroups=#!topic/ceylon-dev/mIrroqhcf7o

UPDATE 2: It was very remiss of me to not mention that we've had support for reified generics in the JavaScript backend for a while now. Thanks, Enrique!

Ceylon M4 was released back at the end of October, more than three months ago, so you might be wondering what the hell have we been up to and where in hell is that M5 release we promised! At the very least you deserve a progress report.

So what's going on is that M5 has gone quite a bit off the roadmap. This was kind of my last chance to revisit some design choices I made a couple of years ago before there was any kind of compiler for Ceylon or libraries written in Ceylon. Inevitably, there were some things that seemed like a good idea at the time, but:

• I never really managed to sell to everyone else,
• we ended up falling out of love with, or
• just didn't quite work out in practice once we started writing real code.

This was really our last opportunity to fix things like that, so we've lost some time there.

Additionally, there was one thing, namely tuples, that I didn't think we were going to need, that we did wind up needing, and accommodating it elegantly into the language was actually somewhat disruptive. This also cost some time, and there is still some unfinished work there.

Finally, we decided to throw away almost all the human-compiled code in the language module and compile it with the Ceylon compiler instead. That was hard work, but it sure makes as feel a lot more secure and saves us a lot of pain when we add things to the language module.

So the bad news is that, given the above, some functionality is going to slip from M5, and therefore M5 will not be a feature-complete implementation of the language. In particular, it wont have support for:

• annotations,
• serialization, or
• the metamodel (reflection).

It will have the following new features:

• tuples
• direct interop with native JavaScript APIs via the new dynamic block (more on this in a separate post)
• the : operator
• verbatim strings
• fat arrow => abbreviation for defining single-expression functions
• the late annotation
• binary and hexadecimal numeric literals
• defaulted type parameters
• experimental support for reified generics
• many miscellaneous minor improvements to the syntax and typing rules of the language
• ceylon.time module
• ceylon.net.httpd package (a HTTP server)
• the compose() and curry() functions

(Please don't try to tell me that's not a pretty impressive list!)

I also finally found the time to give the language specification some love, after several months of neglect, so it's now up to date with all this new work. Ceylon is a better language now, I'm certain of it.

Well, I've a little more bad news: M5 is still not ready :-(

• Stef's currently putting the finishing touches on his initial implementation of reified generics,
• David's working on some performance issues with compilation inside the IDE that we would prefer to see fixed in M5,
• Roland Tepp is finishing off work on the initial release of ceylon.time,
• Matej Lazar is doing some API improvements to ceylon.net.httpd, and
• there's still a bunch of backend bugs that need fixing.

Bear with us. It's frankly very painful for us to have not had a release in almost four months, but in a funny way that's more of a sign of how close we are now to delivering something you can really use to write real applications.

Today we would like to introduce a new eclipse plugin that allows you to run ceylon unit tests, and easily monitor their execution and their output.

It offers similar comfort and integration with IDE as JUnit and even more. Finally, it is part of the Ceylon IDE, so no additional installation is needed.

Getting started with your first ceylon unit test

The new test framework is in the Ceylon SDK module ceylon.test, though this is still an early version and contains only basic functionality, because we need annotations and meta-model support to make it really flamboyant.

So let’s start by importing the ceylon.test module in our module descriptor and writing our first test.

module com.acme.foo '1.0.0' {
    import ceylon.test '0.4';
}

import ceylon.test { ... }

void shouldAlwaysSuccess() {
    assertEquals(1, 1);
}

void shouldAlwaysFail() {
    fail("crash !!!");
}

These tests can be run like any ordinary ceylon application with the following code:

void run() {
    TestRunner testRunner = TestRunner();
    testRunner.addTestListener(PrintingTestListener());
    testRunner.addTest("com.acme.foo::shouldAlwaysSuccess", shouldAlwaysSuccess);
    testRunner.addTest("com.acme.foo::shouldAlwaysFail", shouldAlwaysFail);
    testRunner.run();
}

Which outputs:

======================== TESTS STARTED =======================
com.acme.foo::shouldAlwaysSuccess
com.acme.foo::shouldAlwaysFail
======================== TESTS RESULT ========================
run:     2
success: 1
failure: 1
error:   0
======================== TESTS FAILED ========================

Now let’s see the IDE integrations!

Launch configuration

Once you have created your tests, you can create a Ceylon Test Launch Configuration. In this dialog you can specify the tests to run, their arguments, run-time environment, etc…

In the launch configuration you can directly add test methods or whole containers, like classes, packages, modules, or entire projects.

As you would expect, a quick way to run ceylon tests is to right click in the Ceylon Explorer or in open editor and select Run-As → Ceylon Test.

Viewing test results

The Ceylon Test View shows you the tests run progress and their status. The toolbar has familiar functions:

• show next/previous failure,
• collapse/expand all nodes,
• filter to only show failing tests,
• scroll lock,
• buttons for relaunching or terminating,
• test runs history, and
• menu for view customisation (show elapsed time or show tests grouped by packages).

Comparing test results

In Test Runs History you can review test runs history and switch between runs.

But the real killer feature here happens if you open Compare Test Runs dialog, where you can see which tests have regressed, which tests have been fixed and which tests have been added or removed between two test runs, making it extra easy to get an idea of what your recent work did to the test suite.

Try it now

You can try it right away by downloading one of our Ceylon IDE development build.