Examples used in this article are available at https://github.com/abreslav/kara-files/blob/master/src/tutorial.kt and https://github.com/abreslav/kara-files/blob/master/src/small_builder.kt

Slides from my talk given at JPoint in Saint Petersburg are also available online.
The talk was given in Russian, video accessible is here.

The topic of my talk is “Language Design Trade-Offs (Kotlin and Beyond)“, so one can summarize it as “why designing languages is SO interesting”.

Abstract

If your programming language is small, you’re probably born before 1950, and your first computer was bigger than your present apartment. And even those languages are not so small. One spends quite some time to master a programming language. Why?

Because there are very many decisions “compressed” into the form of a language. Nothing limits a programmer’s imagination like a compiler, and nothing limits a language design like a real world with all of its “legacy”, compatibility concerns, performance limitations, generations-old habits and leaky abstractions.

This talk is about tradeoffs: why we, as language designers, do (or rather did) this and not that.

See you on Friday, 14 June 2013 11:30 @ Room 2

http://geekout.ee/schedule/andrey-breslav-jetbrains-building-jvm-languages/

UPD:

• Slides for this talk
• More slides and videos about Kotlin

IntelliJ IDEA 12.1 and 13

First early access versions of IntelliJ IDEA 13 are coming out, and we ship a Kotlin plugin compatible with these versions. Remember it’s an EAP, use it at your own risk. Of course, good old IntelliJ IDEA 12.1 is supported as well.

Note: Some news about Kotlin support in Android Studio are coming soon.

Many Improvements

As usual M5.3 brings many improvements both in the compiler and the IDE. In the compiler we are still mostly concerned with performance, which is gradually improving. The IDE gets new quick fixes and refactorings, some of which are described below. You can now navigate to properties overriding the one you are looking at (see icons in the left gutter). The editor recognizes the syntax of KDoc (thanks to this pull request)… But first, let’s talk about cool new language features, some long awaited, some unexpected (maybe).

New Language Feature: Delegated Properties

We often get feature requests like:

• Support lazy properties: the value gets computed only upon first access.
• Support observable properties: listeners get notified about changes to this property.
• Support storing properties in a map, not in separate field each.
• Support <my favorite kind of property semantics>…

One way of addressing these requests would be to say that life is tough and users have to suffer. Another way would be to support different kinds of properties on the language level. We do not like either of these approaches: too many unhappy users on the one hand, too many ad hoc features on the other hand. So, we take a third approach: support a unified mechanism that covers all these requests (and probably more), so that particular kinds of properties can be implemented in libraries, without altering the language.

Meet delegated properties:

class Example {
  var p: String by Delegate()
}

There’s some new syntax: you can say “val <property name>: <Type> by <expression>”. The expression after by is the delegate, because get() and set() methods corresponding to the property will be delegated to it.  Property delegates don’t have to implement any interface, but they have to provide methods named get() and set() to be called. For example:

class Delegate() {
  fun get(thisRef: Any?, prop: PropertyMetadata): String {
    return "$thisRef, thank you for delegating '${prop.name}' to me!"
  }

  fun set(thisRef: Any?, prop: PropertyMetadata, value: String) {
    println("$value has been assigned")
  }
}

When we read from p, the get() function from Delegate is called, so that its first parameter is the object we read p from and the second parameter holds a description of p itself (e.g. you can take its name). For example:

val e = Example()
println(e.p)

This prints “Example@33a17727, thank you for delegating ‘p’ to me!” Similarly, when we assign to p, the set() function is called. The first two parameters are the same, and the third hold the value being assigned:

e.p = "NEW"

This prints “NEW has been assigned to ‘p’ in Example@33a17727″.

Probably, you already see how to implement things like lazy or observable with this mechanism. Try it as a metter of exercise, but most of it is already done in the standard library.

The kotlin.properties.Delegates object holds the most useful stuff. Let’s start with lazy:

import kotlin.properties.Delegates

class LazySample {
    val lazy: String by Delegates.lazy {
        println("computed!")
        "Hello"
    }
}

Delegates.lazy() is a function that returns a delegate that implements a lazy property: the first call to get() executes the lambda expression passed to lazy() as an argument and remembers the result, subsequent calls to get() simply return the remembered result. If you want thread safety, use blockingLazy() instead: it guarantees that the values will be computed only in one thread, and that all threads will see the same value.

Now, let’s turn to observable:

class User {
    var name: String by Delegates.observable("<no name>") {
        d, old, new ->
        println("$old -> $new")
    }
}

The observable() function takes two arguments: initial value and a handler for modifications. The handler gets called every time we assign to ‘name’, it has three parameters: a property being assigned to, the old value and the new one. If you want to be able to ‘veto’ the assignment, use vetoable() instead of observable().

Next may be somewhat unexpected: users frequently ask what to do when you have a non-null var, but you don’t have an appropriate value to assign to it in constructor (i.e. it must be assigned later)? You can’t have an uninitialized non-abstract property in Kotlin:

class Foo {
  var bar: Bar // error: must be initialized
}

You could initialize it with null, bit then you’d have to check every time you access it. Now you have a delegate to handle this:

class Foo {
  var bar: Bar by Delegates.notNull()
}

If you read from this property before writing to it, it throws an exception, after the first assignment it works as expected.

The last thing to show is properties stored in a map. This comes up a lot in applications like parsing JSON or doing other “dynamic” stuff:

class User(val map: Map<String, Any?>) {
    val name: String by Delegates.mapVal(map)
    val age: Int     by Delegates.mapVal(map)
}

In this example, the constructor takes a map:

val user = User(mapOf(
    "name" to "John Doe",
    "age"  to 25
))

Delegates take values from this map (by the string keys – names of properties):

println(user.name) // Prints "John Doe"
println(user.age)  // Prints 25

Of course, you can have var’s as well (with mapVar() function), that will modify the map upon assignment (note that you’d need MutableMap instead of read-only Map).

There are other use cases, and probably numerous improvements to these ones. Fantasize, experiment, enjoy!

First Steps in SAM Conversions

We introduced SAM constructors last time. Of course, this is not enough, so we are working on full SAM conversions. The feature is not finished yet, but you can already use it in simple case like this:

SwingUtilities.invokeLater {
  button.setVisible(true)
}

To remind you, SAM conversions is what Java 8 uses for lambdas: when you have an interface with only one (abstract) method, like Comparator or Runnable, you are allowed to pass in a lambda where an instance of this interface is expected (in this example we pass a lambda instead of a Runnable). Kotlin does not have this as a language feature (for it is not needed in a language with proper function types), so it will only work for Java classes.

First Steps in “Callable References”

Another thing we are working on is “Callable References” or “Feature Literals”, i.e. an ability to pass named functions or properties as values. Users often ask “I have a foo() function, how do I pass it as an argument?”. The answer is: “you prefix it with a ‘::’”. For example:

fun isOdd(x: Int) = x % 2 != 0

val numbers = listOf(1, 2, 3)
println(numbers.filter(::isOdd)) // Prints [1, 3]

Here “::isOdd” is a value of function type “(Int) -> Boolean”, and you can pass it as a filtering predicate. Another example:

fun compose<A, B, C>(f: (B) -> C, g: (A) -> B): (A) -> C {
    return {x -> f(g(x))}
}

This function return a composition of two functions passed to it: compose(f, g) = f(g(*)). Now, you can apply it to callable references:

fun length(s: String) = s.size

val oddLength = compose(::isOdd, ::length)
val strings = listOf("a", "ab", "abc")
println(strings.filter(oddLength)) // Prints "[a, abc]"

If you want to use a member of a class, you need to qualify it, and the result will be of type “extension function”,  e.g. String::toCharArray gives you an extension function for type String.

Note that this is early work in progress, so many things do not work yet, for example, overload disambiguation, type inference, support for properties etc. Eventually this feature will evolve into full type-safe reflection, but today we are only starting working on it.

Change Signature Refactoring

Adding/removing/reordering function parameters may be tedious when you have a lot of call sites to update. That’s why IDEs prove a “Change Signature” refactoring. Place your cursor on a function or a constructor and hit Ctrl+F6 (Cmd+F6 on Mac), and you’ll get a dialog like this:

Change type, rename, reorder or delete parameters and all your call sites will be updates accordingly.

Quick Fixes for “Type Mismatch” etc

Thanks to contributions by Jack Zhou, Michał Sapalski, Wojciech Łopata and other students of Open Source Mentorship program led by Stanford University, we now get many cool quick fixes. For example, when you get a type mismatch error, hit Alt+Enter and get some proposals to fix your code:

Code Transformations

Another group of useful IDE actions to convert between equivalent forms of code, like:

You can also use Ctrl+Shift+Up/Down to move statements or declarations:

Installation

As usual, the new plugin can be installed from our plugin repository.

Have a nice Kotlin!

Support for New IntelliJ IDEA

Koltin M5.2 supports (in fact, requires) the recently released IntelliJ IDEA 12.1.

The Kotlin IDE improvements include:

• Kotlin classes in the Class Hierarchy view. Just hit Ctrl+H on a class name to see its descendants and/or parents.
• Folding for imports (you don’t have to scroll through imports to get to your code any more).
• New UI for Kotlin library configuration: you can now control library names and location, and kotlin-runtime.jar is not copied to your project by default. It just works.
• Support for JavaScript-targeted modules is significantly improved.
• Optimizing imports on the fly: IDE Settings -> Editor -> Auto Import -> Optimize imports on the fly.
• New quick fixes: place the cursor on an error, and hit Alt+Enter.

SAM Constructors

When using Java libraries, you can now create an instance of a SAM interface (one with a Single Abstract Method) by calling its name and passing a function literal. For example:

SwingUtilities.invokeLater(Runnable { doItNow() })

This works only for Java classes. In fact, it is not a part of the language, but a feature of how Java classes are loaded into Kotlin: we define a synthesized function

fun Runnable(body: () -> Unit) = object : Runnable {
    override fun run() {
        body()
    }
}

So whenever you import Runnable, the function is there too, and you can use it.

This is the first chunk of SAM-conversion support for Java. Real SAM conversions will come soon, and you’ll be able to say simply

SwingUtilities.invokeLater { doItNow(); }

New Gradle Plugin

Starting with M5.2, in addition to the long-available Maven plugin, there’s a Gradle plugin for Kotlin from JetBrains.

Here’s an example for building a Kotlin module with Gradle:

buildscript {
  repositories {
    mavenCentral()
    maven {
      url 'http://repository.jetbrains.com/all'
    }
  }
  dependencies {
    classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:0.1-SNAPSHOT'
  }
}

apply plugin: "kotlin"

repositories {
  mavenCentral()
  maven {
    url 'http://repository.jetbrains.com/all'
  }
}

dependencies {
  compile 'org.jetbrains.kotlin:kotlin-stdlib:0.1-SNAPSHOT'
}

More examples & docs can be found here.

Reminder: KAnnotator

Don’t forget that you now have KAnnotator at your service.

Have a nice Kotlin!

mf = (. map) . (.) . filter

This function, written in Haskell, composes a map() function with a filter() function. As you can see, point-free style largely relies on dots.

Kotlin is not a functional language per se, but we are happy to borrow useful features from other languages. So, today I’ll write about dots.

The Dot

We introduce the dot operator in Kotlin. As usual, it works by convention. If there’s a function like this

fun Foo.dot() {
    println("a dot!")
}

it will be called whenever there’s a dot (“.”) after an expression of type Foo:

fun test(f: Foo) {
    f.foo()
    Foo().bar().baz()
}

This function prints “a dot!” twice: once for each dot after a Foo. The bar() function doesn’t return a Foo, so the dot after it doesn’t count.

Dot Chaining

What if my dot() function returned something, for example, another Foo?

class Foo(val count: Int)

fun Foo.dot(): Foo {
    return Foo(count + 1)
}

then, of course, it’s result is used to call whatever comes after the dot:

println(Foo(1).count)

This prints 2, because the dot() function returned a new Foo with an increased counter.

As you can see, the dot operator gives us a lot of power and addresses most of the issues previously tackled only by aspect-oriented programming.

Flavors of the Dot

The real power of the dot operator comes in when you declare it with a parameter:

fun Any.dot(p: Dot) {
   ...
}

The parameter must be of the Dot type, of which there are a few interesting predefined values:

LEFT
RIGHT
TOP
BOTTOM

These values correspond, obviously, to the position of the dot:

fun test() {
    println(a.b[1..2])
}

One might think that in this example dot() is called three times: one for “a.b”, with the argument BOTTOM, then twice for “1..2″: first with LEFT, and then with RIGHT (these are not two BOTTOMs, because “..” is a single token in Kotlin), but in fact it gets called four times, and the fourth time (in fact it comes first) with TOP as an argument.

I’m sure you already see why: in Kotlin, we never forget to dot out i’s, and that dot counts as well; its position is clearly TOP (we could introduce a separate tittle() function, but we found it too inconvenient). Tittles above j’s count just as well, same for dots in ; ! ? etc.

The Depth of the Dot

You may be wondering what happens if dot() is defined like this:

fun Foo.dot() {
    println(this.count)
}

There is a dot after this, which has type Foo, in the body of Foo.dot() function itself, so dot() should be called recursively at that point and, seemingly, never terminate. This is called a higher-order dot, and is executed only if there’s a function dot1() defined on Foo. If dot1(), in turn, contains a higher-order dot, then dot2() is called and so on:

fun Foo.dot1() {
    println(this.count) // a call to dot2() if that is defined
}

This corresponds to Russel’s approach to set theory called type theory (with its notion of a class), which lies the solid foundation for statically-typed object-oriented programming.

Conclusion

We are planning to support the dot operator very soon. The first version will be restricted to basic ASCII characters such as . : ; ! ? and, of course i, but in the future we plan to expand it to other characters like ё.

Have a nice Dot!

Why Infer Annotations

An excerpt from an earlier blog post, explaining what KAnnotator is:

Since Kotlin M3, you can use external annotations to tell the system that your methods return/take non-null values. This mechanism is useful even if you don’t use Kotlin: you can turn on nullability inspections for Java too (and I totally recommend you to do so).

One problem about this used to be that, while you can annotate your own code while you write it (and we do it all the time at JetBrains), your favorite library is not annotated, and it is so big, you can’t annotate it manually.

The key thing here is that ‘manually’. A programmer is a lazy creature, and by virtue of our laziness, we want to automate as much as we can. KAnnotator is a tool that annotates your libraries automatically (the tool is written in Kotlin, of course).

How it works, in a nutshell: you have your library as a jar (or a number of jars), you tell KAnnotator to infer annotations for these jars, and get a bunch of .xml files back. They contain annotations for methods and fields, for example:

Now, you can attach these annotations to your project, and both Java IDE and Kotlin compiler will see them.

We used KAnnotator to infer annotations for JDK that ship with Kotlin. Now you can use it as well: to annotate your own libraries.

Install

KAnnotator ships as a separate plugin for IntelliJ IDEA 12 or higher (both 12.0.4 and 12.1 will work). Note that the Kotlin plugin is not required. To install the plugin, follow the instructions from here.

Infer

No you can call Analyze -> Annotate Jar Files… (from either Main menu or context menu)

You get a dialog like this:

There you specify what JAR files you want analyzed and where to put the results, i.e. XML files containing annotations. By default, KAnnotator will attach the annotation to the libraries you call it on.

Enjoy

So, when you see Kotlin complaining about nullable types coming from Java, all you need to do is run KAnnotator once on that Java library, and it will turn your red code green.

If it does not, maybe KAnnotator is not smart enough, but maybe that method actually returns null?

Kotlin: Beyond Dogmatism
Thursday, March 14th, 10:10 AM – 11:10 AM, Room D

Kotlin is a new language developed by JetBrains and licenses under Apache 2 OSS License, targeting the JVM and JavaScript. When presented, the typical questions asked are “Why another language? What core fundamentals does it bring to the table?” Tell you what, let’s move beyond dogmatism and be pragmatic. Let’s focus on the problems we’re trying to solve when developing applications and see why and how Kotlin can help us.

Developers: Prima Donnas of the 21st Century
Friday, March 15th from 13:10 – 14:10

“We are developers. We are creators. We are misunderstood by customers, by managers and even co-workers; we are undervalued and often overworked. People don’t appreciate the value we put in our craft and our drive for innovation. We are central to business in the 21st century yet people don’t appreciate us!” Of course you are, but you also forgot to mention: You suck at communication. You often put business at risk based on personal ambitions and waste serious amounts of time trying to improve and discuss the wrong things, all in the name of the next great thing that’s going to solve it all. You’ve completely forgotten the plot! Don’t believe me? Why don’t you come along to this talk and get a wakeup call. But don’t expect to be treated nicely.

For full details on the event please visit 33rd Degree Conference website.

Better Support for Scala Classes. Akka

Theoretically, it is very easy for all JVM languages to interoperate. In practice, there appear to be numerous little problems that make it unpleasant or practically impossible.

One of such problems was related to the ambiguous use of “$” signs in class names, which is a well-known issue on the JVM. It being fixed now, allows you to use some Akka classes you couldn’t use before, such as Duration.

To get an impression of what Akka looks like in Kotlin, have a look at this example.

Even More Helpful IDE

With the help of students of Cornell and Jagiellonian universities, we got quite a few quick fixes implemented in M5.1. When the IDE complains about some error or warns you, you can simply press Alt+Enter and get a list of proposed fixes:

Parameters are Immutable

We removed support for mutable parameters, as in

fun foo(var x: Int) {
  x = 5
}

The main reason is that this was confusing: people tend to think that this means passing a parameter by reference, which we do not support (it is costly at runtime). Another source of confusion is primary constructors: “val” or “var” in a constructor declaration means something different from the same thing if a function declarations (namely, it creates a property). Also, we all know that mutating parameters is no good style, so writing “val” or “var” infront of a parameter in a function, catch block of for-loop is no longer allowed.

If some of your existing code breaks, you can quick-fix the whole project in one click using the IDE:

Support for Java’s protected static methods

Some Java frameworks, like Android, rely on protected static methods to be available in subclasses. Although this seems like a questionable pattern, Kotlin now supports it (only for Java compatibility), i.e. you can access a protected static member of a Java class if you extend this class in Kotlin.

Anonymous Objects

Consider the following code (that uses a Kotlin analog to anonymous inner class):

val x = object : A() { ... }

What is the type of x? It used to be the anonymous type, but if you use x from the outside, you can not access it: the type is not valid. Now the type will be A. This applies only to properties that can be seen from the outside, i.e. if x is a local variable it will still have the anonymous type, since it is harmless.

Class Objects are Usable from Java

Kotlin classes do not have static members, but rather have class objects:

class A {
    class object {
        val x = 1
    }
}

Now, with a few bugs fixed, you can access members of class objects from your Java code:

public static void main(String[] args) {
    System.out.println(A.object.instance$.getX());
}

Compiler

The compiler is being improved too: a few fixes for corner cases of nullable types interacting with generics and optimizations for loops over ranges.

Requirements

Kotlin M5.1 requires IntelliJ IDEA 12.0.4 (EAPs of 12.1 are not supported yet), you can download it from the plugin repository.

Have a nice Kotlin!

What is the “Surround with…” action?

This action allows you to surround a block of code with if, try or other statements (see the full list bellow). Simply select a block of code, press Ctrl + Alt + T and choose the template (Cmd + Alt + T for Mac):

The IDE will add the neccessary code and put the caret at the position that allows you to finish your refactoring:

If the surrounded block contains variable declarations that are used after the block, they will be moved out of the block:

Function Literal Template

You can surround a block of code like this:

Use this template if you want to “hide” some variables in the scope of the block, to create a property with function type or a local function and if you want to call any function with function literal as an argument.

When template

You don’t need to write when expression by hand any more: you can simply select a subject expression, choose “surround with when(expr) {}” and the result will be:

Full list of  “Surround with…” templates

When a block of code is selected:

• if
• if / else
• { }                       – function literal
• try
• try / catch
• try / catch / finally

When an expression is selected:

• !(expr)                – add negation for Boolean
• (expr)                 – surround with parentheses
• “${expr}”           – surround with quotes
• when(expr) {}

Kotlin M5.1

We release “Surround with…” as a part of Kotlin M5.1 that will be out very soon.

Range expressions are formed with rangeTo functions that have the operator form of .. which are complemented by in and !in. Range is defined for any comparable type (subclass of Comparable), but for number primitives it is optimized. Here are examples of using ranges:

if (i in 1..10) { // equivalent of 1 <= i && i <= 10
  println(i)
} 

if (x !in 1.0..3.0) println(x) 

if (str in "island".."isle") println(str)
// equivalent of "island" <= str && str <= "isle"

Numerical ranges have extra feature: they can be iterated over. Compiler takes care about converting this in simple analogue of Java’s indexed for-loop, without extra overhead. Examples:

for (i in 1..4) print(i) // prints "1234"  

for (i in 4..1) print(i) // prints nothing 

for (x in 1.0..2.0) print("$x ") // prints "1.0 2.0 "

What if you want to iterate over numbers in reversed order? It’s simple. You can use downTo() function defined in standard library:

for (i in 4 downTo 1) print(i) // prints "4321"

Is it possible to iterate over numbers with arbitrary step, not equal to 1? Sure, step() function will help you:

for (i in 1..4 step 2) print(i) // prints "13"  

for (i in 4 downTo 1 step 2) print(i) // prints "42"  

for (i in 1.0..2.0 step 0.3) print("$x ") // prints "1.0 1.3 1.6 1.9 "

How it works

There are two traits in the library: Range<T> and Progression<N>.

Range<T> denotes an interval in the mathematical sense, defined for comparable types. It has two endpoints: start and end, which are included in the range. Main operation is contains(), usually used in the form of in/!in operators.

Progression<N> denotes arithmetic progression, defined for number types. It has start, end and non-zero increment. Progression<N> is a subtype of Iterable<N>, so it can be used in for-loops and functions like map, filter, etc. First element is start, every next element equals previous plus increment. Iteration over Progression is equivalent to an indexed for-loop in Java/JavaScript:

// if increment > 0
for (int i = start; i <= end; i += increment) {
  // ...
}

// if increment < 0
for (int i = start; i >= end; i += increment) {
  // ...
}

For numbers, the “..” operator creates an object which is both Range and Progression. Result of downTo() and step() functions is always a Progression.