Hacker News Reader

> Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions.

For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and in codebases that likely have some non-functional sections, particularly if you're interoperating with Java) being able to be 100% sure that a given value is really immutable rather than 99.9% sure makes a huge difference.

> Re "command-like" objects: I'm not following, can you give an example of something you can do in Scala here that you can't in Kotlin?

There are lots of different use cases for this stuff, but one I was working with today was database transactions. I have operations that should only happen inside a database transaction, and want to enforce that at the type level, but I want to be able to compose several of those functions in a single database transaction, so I don't want to just have each one run its own transaction. So what I do is have a custom type, something like MustHappenInTransaction[A], which is actually just an alias for an existing library type (Free), and I automatically get the ability to use the for/yield syntax to compose these, and can use existing library functions to operate on it almost as if it were a plain value, but still safely (e.g. traverse rather than map on a sequence). I have no way to "get the A out" except for my doTransaction() function (what's why I say it's a command-like object), so the function will definitely happen in a transaction, but I can still do normal function composition, extract out common subfunctions, and all that.

You can't do that in Kotlin because there's no equivalent to "do notation" or "for comprehension" that you can use for user-defined types, and there are no higher-kinded types so you can't implement generic helper functions like traverse (there's no way to write the type signature it should have).

View on HN

class MyTransaction { fun begin() {} fun commit() {} } fun MyTransaction.query() {} fun MyTransaction.update() {} inline fun <R> transaction(tblock: MyTransaction.() -> R): R { val t = MyTransaction() t.begin() try { return t.tblock() } finally { t.commit() } } fun test() { // update() doesn't compile, no such method val hello = transaction { query() update() query() "Hello" } println("$hello") // prints "Hello" }

typealias MustBeInTransaction = MyTransaction.() -> Unit fun makeObject(i: Int): MustBeInTransaction { return { /* do something with i or whatever in a transaction */ } } fun test() { var genericArray = arrayOf(1, 2, 3).map { makeObject(it) } //genericArray.forEach { it() } // fails to compile transaction { genericArray.forEach { it() } } }

type MustBeInTransaction = implicit MyTransaction => Unit def makeObject(i: Int): MustBeInTransaction = { return { /* do something with i or whatever in a transaction */ } } def test(): Unit = { var genericArray = Array(1, 2, 3).map(makeObject) //genericArray.forEach { _() } // fails to compile transaction { genericArray.forEach { _() } } }

def test() { // update() compiles but doesn't do anything to the DB val helloDBOperation = for { result1 <- query() _ <- update() result2 <- query2() } yield "Hello" println("$hello") // prints "Hello" }

def test(): Unit = { // update() compiles but doesn't do anything to the DB val helloDBOperation = for { _ <- query() _ <- update() _ <- query2() } yield "Hello" val hello = db.run(helloDBOperation) println("$hello") // prints "Hello" }