Ceylon v.s. Kotlin

void function

Kotlin uses Unit for functions returning nothing, like many functional languages, while Ceylon uses void keyword. void functions in Ceylon actually returns Anything. This allows to use other non-void functions when void functions are expected, and other non-void functions to accept void function as parameter.

Ceylon's Anything approach is flexible, but it may not fit in a more disciplined coding style. If non-void functions are used when void functions are expected, then we are using side effects with non-void functions. But a non-void function should avoid exposing side effects.

We can declare our own Unit class in Ceylon:

 1abstract class Unit() of unit {}
 2object unit extends Unit() {}
 3
 4Unit f() {
 5    print("hi");
 6    return unit;
 7}
 8
 9shared void run() {
10    f();
11}

Like assignment returning a value, Ceylon's behavior may also be influenced by C. In C, any function can be converted to void via (void) f, discarding its return value.

Variadic arguments

Kotlin uses vararg keyword to mark variadic argument, while Ceylon just types them with T* or T+ (at least have an argument). This is an example of Ceylon's regularity of type system. Kotlin uses Array<T> for vararg p: T underhood but special array types for basic types, e.g. IntArray for vararg p: Int. However, p: Array<T> and vararg p: T behaves differently. In other words, given a function Array<T> -> Unit, we do not know how to invoke it just from its signature.

Function reference

Kotlin's function reference syntax is strange:

1fun gf(x: Double, f: (Double) -> Double): Double {
2    return f(x)
3}
4gf(2.0, ::findFixPoint)

Without :: it will not work.

Languages using special function reference syntax usually saves f for f(). But that is not allowed in Kotlin, either. Instead, Kotlin saves f for a variable/property f with the same name!

1val i = 2
2fun i(): Int { return 2 };
3print(i)
4print(i())

Still Kotlin compiler cannot resolve the function reference if there is a property which has the same name:

1fun h(f: () -> Int) {
2    print(f())
3}
4h(::i) // error: overload resolution ambiguity

Also, Kotlin only allows reference to Foo::bar not foo::bar.

For anonymous function, there is no ambiguity. Thus the function reference is normal.

1val f = fun(): Int { return 1 }
2h(i)

Ceylon's function reference is normal.

Ceylon does not support overloading. And function reference will not work for Java overloading functions.

Inline functions

Kotlin supports inline functions.

1inline fun foo(inlined: () -> Unit, noinline notInlined: () -> Unit) {}
2inline fun f(crossinline body: () -> Unit) {
3    val f = object: Runnable {
4        // body is called in another context `object: Runnable`,
5        // thus we need the `crossinline` keyword.
6        override fun run() = body()
7    }
8    // ...
9}

Kotlin's inline function supports reified generics:

1inline fun <reified T> TreeNode.findParentOfType(): T? {
2    var p = parent
3    while (p != null && p !is T) {
4        p = p?.parent
5    }
6    return p as T
7}

Ceylon does not support inline functions, and all generics are reified, except interoperation with Java code.

IMO, languages should make function calls cheap, instead of bring in confusing inline features.

Object

Kotlin's object looks like class, and provides an invoke method to mimic function call with object initialization.

1object SingletonExample {
2   fun singletonMethod() {
3        return "We cannot initialize a singleton."
4   }
5   operator fun invoke() {
6        return "`invoke` will be called when we write `SingletonExample()`."
7   }
8}

I dislike this feature. Now every time I see CapsName(something) I am not sure it returns an instance of CapsName. It may return anything!

Ceylon's object does not have a invoke method.

1shared object consoleWriter satisfies Writer {
2    formatter = StringFormatter();
3    write(String string) => process.write(string);
4}

The downside of object (anonymous class) in Ceylon is if we ever need to write code that refers to the concrete type consoleWriter, we must use the very ugly syntax \IconsoleWriter as the type name. A toplevel object in Ceylon is a singleton.

Object (anonymous class) in Ceylon is actually a value constructor:

1// object thing {}
2class \Ithing {
3    shared new thing {}
4}
5\Ithing thing => \Ithing.thing;

Kotlin also has object expression.

 1val adHoc = object {
 2    var x: Int = 0
 3    var y: Int = 0
 4}
 5open class A(x: Int) {
 6    public open val y: Int = x
 7}
 8
 9interface B
10
11val ab = object : A(1), B {
12    override val y = 15
13}

Object expression in Ceylon:

1return object extends Foo() satisfies Bar {
2    // ...
3};

An object expression is basically a shorthand for a local object declaration.

1object foo extends Foo() satisfies Bar {
2    // ...
3};
4return foo;

Kotlin uses component object to mimic Java static methods:

 1class ExampleClass(val x: Int) {
 2    companion object {
 3        // still a real object at runtime
 4        fun aMethodLooksLikeStaticButNot() = println("not static")
 5        @JvmStatic fun aMethodToBeCompiledToStaticMethodOnJVM() {
 6            println("compiled to static methods on JVM")
 7        }
 8    }
 9}
10ExampleClass.aMethodLooksLikeStaticButNot()
11ExampleClass.aMethodToBeCompiledToStaticMethodOnJVM()

Ceylon does not support this.

Both Kotlin and Ceylon support top level function declaration, something like package level static method.

Ceylon 1.3.1 introduces static member.

Also, Kotlin supports extension method. Extension method on Kotlin is resolved statically, only providing a way to call with Class.method syntax, not actually modifying the extended class.

Similarly to functions, Kotlin supports extension properties. Again, Ceylon does not support this.

Final class

Classes in Kotlin are final by default. Also, Kotlin requires explicit open modifier for overridable members. And a member marked override is itself open. Also, properties declared in Interface are open.

1open class OpenClass(x: Int) {
2    open fun overridableMember() {}
3}
4open class ChildOfOpenClass(x: Int) : OpenClass(x) {
5    override fun overridableMember() {}
6}

Ceylon classes are by default open, unless annotated with final. However, Ceylon also requires explicit annotation for overridable members:

• formal for declaration without implementation,
• default for open in Kotlin,
• actual for override in Kotlin (no default unless denoted).

Also, attributes in interface are not open by default in Kotlin. You need to explicitly annotate it as formal.

super ambiguity

Kotlin uses super<A>.f().

 1open class A() {
 2    open fun f() { print("A") }
 3}
 4
 5interface B {
 6    // Interface members are open by default.
 7    fun f() { print("B") }  // Allowing method implementations, like Java 8.
 8}
 9
10class ChildOfAB() : A(), B {
11    // The compiler requires `f()` to be overridden.
12    // So you do not need to remember rules of priorities
13    // and check super class definitions for possible conflicts.
14    override fun f() {
15        super<A>.f()
16        super<B>.f()
17    }
18}

Ceylon uses (super of A).f().

1class SelfReference() {
2    // Ceylon has keywords `this` and `super`.
3    // To deal with ambiguity of what `super` refers to, use the widening operator.
4    class Impl() extends Class() satisfies Interface {
5    // Suppose Impl inherits two different implementations of `ambiguous`
6    // from Class and Interface.
7        (super of Interface).ambiguous()
8    }
9}

getter and setter

Kotlin uses get() and set() functions with optional backing field:

 1class GettersAndSetters(val x: Int) {
 2    var isEmpty: Boolean = null
 3        get() = this.x == 0
 4        // By convention, the name of the setter parameter is value,
 5        // but you can choose a different name if you prefer.
 6        set(value) {
 7            if (value == null) {
 8                // Kotlin provides an automatic backing `field`.
 9                field = false
10            } else {
11                // The field identifier can only be used in the accessors of the property.
12                field = value
13            }
14        }
15}

Ceylon uses anonymous setter and assign for getter, without backing field.

 1class GetterSetterExample() {
 2    variable String? rank = null;  // Ceylon never auto initializes to null.
 3    variable String? comment = null;
 4    shared String review => "``rank``: ``comment``";
 5    assign review {
 6        value tokens = review.split(":").iterator();
 7        if (is String first = tokens.next()) {  // narrowing down types
 8            rank = first;
 9        }
10        if (is String second = tokens.next()) {
11            comment = second;
12        }
13    }
14}

In Kotlin, immutable variable val does not allow setter. Ceylon's getter and setter are more flexible. In the above example, we have a setter for immutable review. The setter is valid, since it actually changes value of mutable rank and comment.

const

Kotlin has compile time const:

const val VERSION: String = "alpha"

const only allows String or a primitive type.

Ceylon does not have this.

I have no idea why this need to be explicitly marked in Kotlin. The compiler cannot automatically optimize this?

late init

Kotlin has lateinit and Ceylon has late annotation. But they are two different things.

Kotlin only allows non-nullable, not-primitive types to use lateinit. Kotlin uses the null value to mark that a lateinit property has not been initialized and to throw the appropriate exception when the property is accessed. But primitive Java types can't have a 'null' value. In other words, the property must be not nullable in Kotlin level, but nullable in Java level.

 1public class MyTest {
 2    lateinit var subject: TestSubject
 3
 4    @SetUp fun setup() {
 5        subject = TestSubject()
 6    }
 7
 8    @Test fun test() {
 9        subject.method()
10    }
11}

Ceylon uses late to suppress definite initialization checks. In Ceylon, all declaration is done after initialization, which may cause problems on circular reference.

 1class Child(parent) {
 2    shared late Parent parent;
 3}
 4
 5class Parent() {
 6    // This won't work,
 7    // because `this` refers to an instance of Parent in its own initializer section,
 8    // where Parent has not been initialized yet.
 9    // shared Child child = Child(this);
10    shared Child child = Child();
11    child.parent = this; // ok, since parent is late
12}

declaration-site variance

Both Kotlin and Ceylon uses declaration-site variance <out Bar>.

Ceylon also support use-site variance for interoperation with Java code. So does Kotlin, with a slightly different syntax <out Bar!>!.

Generics constrains

Kotlin uses common T : Upper syntax:

fun <T : Comparable<T>> sort(list: List<T>) {}

More than one upper bounds need to be specify in a where clause:

1fun <T> cloneWhenGretter(list: List<T>, threshold: T): List<T>
2        where T : Cloneable, T : Comparable {
3    return list.filter{it > threshold}.map{it.clone()}
4}

Ceylon has a more consistent syntax, and uses intersection type for more than one upper bounds.

Value genericFunction<Value>(Value num, Value denom)
        given Value satisfies Comparable<Value> & Summable<Value>
        => if num > denom then num else num + denom;

Both Kotlin and Ceylon does not support raw type. Kotlin has a similar star projection syntax:

Given interface Function<in S, out T>, Function<*, *> is a shortcut for Function<in Nothing, out Any?>

Ceylon just supports explicit Function<in Nothing, out Anything>.

Also note that Ceylon uses Anything instead of Any? in Kotlin. Any in Kotlin is not truly Any because it does not hold null. Ceylon's Anything is an enumerated type:

1shared abstract class Anything()
2        of Object | Null {}

of Object | Null can be used in generics as enumerated constrain.

Anonymous function

Kotlin has both anonymous function and lambda:

1// anonymous function
2fun(): Unit { println(numbers.size) }
3// lambda
4{ n: Int -> n <= 0 }
5// one parameter lambda can be abbreviated,
6// also parameter type can be omitted if it can be inferred by compiler
7{ it <= 0 }

The difference between lambda and anonymous function is:

• lambda cannot specify a return type
• control flow return in lambda returns the outer function

Ceylon just have anonymous function.

 1// Same as lambda in Kotlin, an anonymous function cannot specify return type.
 2(Integer n) => n <= 0
 3// Except `void`.
 4void (Integer n, Integer m) => print(m + n)
 5// Mark it with `function`
 6function (Integer n) => n <= 0
 7// Like `function`, `void` can be omitted.
 8() => print("Hi!")
 9// Same as above, with block
10() { print("Hi!"); }
11// Similar to Kotlin's anonymus function
12function () { print("Hi!"); }

case

Kotlin uses when for both case and cond in Scheme.

1when {
2    i == 0 -> false
3    else -> true
4}
5when (i) {
6    0 -> false
7    else -> true
8}

Ceylon just uses switch for case:

 1  void printID(String|Integer id) {
 2      switch (id)
 3      case (is String) {
 4          println(id);
 5      }
 6      case (is Integer) {
 7          switch (id)
 8          case (0) {
 9            println("Error");
10          }
11          else {
12            println("id number: ``id``");
13          }
14      }
15      // No `else` clause since all cases of a union type is exhausted.
16}

Ceylon uses switch as statements, while Kotlin uses when as both statements and expressions.

case must be both disjoint and exhausted in Ceylon.

 1shared abstract class Comparison(shared actual String string)
 2        of larger | smaller | equal {}
 3switch (x<=>y)  //  `<=>`  produces an instance of `Comparison`.
 4case (equal) {
 5    print("same same");
 6}
 7case (smaller) {
 8    print("x smaller");
 9}
10case (larger) {
11    print("y smaller");
12}

Cases must be exhausted in Kotlin only in when expression.

In Ceylon, switch can declare a scoped local variable:

1switch (name = process.arguments.first)
2case (null) {
3    print("Hello world!");
4}
5else {
6    print("Hello ``name``!");
7}

This is frequently used in Ceylon, because Ceylon's case condition does not allow arbitrary expressions. Only conditions like exists, is Type, nonempty and literal values of basic types are allowed.

Catch checked exceptions from Java

Kotlin does not have checked exceptions. So, normally, the Java signatures of Kotlin functions do not declare exceptions thrown. If you want to call them in try catch clause from Java, you need to annotate functions with @Throws(IOException::class).

The root of the exception hierarchy in Ceylon is ceylon.language::Throwable, Unlike Java's Throwable, ceylon.language::Throwable is sealed and the only subclasses available to users are ceylon.language::Exception and ceylon.language::AssertionError.

The JVM implementation of ceylon.language::Exception is a java.lang.RuntimeException. On the other hand, ceylon.language::AssertionError is a java.lang.Error at runtime. This means that pure Ceylon code compiled for the JVM can only generate unchecked exceptions.

Impure Ceylon (that is, Ceylon code which access Java code) may throw any exception that is thrown by that Java code, including checked exceptions. If a Ceylon function may throw checked exceptions, you need to call it in a try catch clause in Java.

Reassignment of function parameters

Kotlin does not allow reassignment of function parameters, i.e. function parameters are always implicitly val, like function parameters are always implicitly let in Swift.

Ceylon disallows this unless the function parameter is annotated as variable. This is consistent with variable declaration.