Idle thought on Saturday: coming from Haskell, one thing that I'm missing in Kotlin is the let..in syntax Am I the only one that would like having something like this? (I've called it LETTING for clarity) A ideal constrain would be that the function should be pure, that is no access to external scope, like singletons, objects, public functions, java System. etc. etc.

is that an apostrophe in your function name, without backticks?

a unicode symbol, to make it compile in haskell fashion 🙂

that seems a little difficult to work with but all right lol

I always hated it. What I'd like to have is where syntax like in haskell

Where or let syntax is not a big difference to me, what I miss is the guarantee that function is pure and not calling anything else

fun pythagora(a: Double, b: Double): Double {
    val x = a * a
    val y = b * b
    return Math.sqrt(x + y)
}

What am I missing?

@Uberto Barbini in the upcoming version of Arrow Fx the linter can verify function purity and effect tracking if you denote effectual functions as

suspend

which is what the Kotlin community already does for the most part when they use the

coroutines-core

lib. The linter will verify that expressions returning

Unit

that are not inside

suspend

functions fail to compile in the same way today the Kotlin compiler verifies that

suspend

functions can't be applied unless in the presence of a continuation. This is the same concept as Haskell's

IO

. Also this can be implemented with no additional syntax in Kotlin, it already supports all this natively thanks to the core continuation intrinsics being part of the std lib.

coroutines-core

implements the runtime for an effect system that tracks

suspend

like Arrow Fx also does but geared more toward guaranteeing purity at compile time vs async concurrency. //@aballano is going to help us with the linter rules, the rest the Kotlin compiler and @RestrictsSuspension already takes care of. This is often ignored in Kotlin because it does not really have the FP names you'd expect but @RestrictsSuspension already allows you to group effects in different areas and prevent compilation unless you explicitly encode how a foreign suspend function is accepted within a restricted context. If interested more info here https://arrow-kt.io/docs/effects/fx/#pure-functions-side-effects-and-program-execution Additionally if this was interesting to the compiler and the general community you could enable an experimental import that disallows returning

Unit

unless you are inside

suspend

. That is all the compiler is missing today to guarantee pure functions.

Thanks @raulraja, I'll look into it

@Uberto Barbini

but the problem is that you can write any code in that pythagora fun, calling db, asking google etc.

Can you, please, clarify how that problem is related to the “letting” syntax?

val x = ... ; val y = ... ; return ...

is just the Kotlin syntax for

let x = ... in let y = ... in ...

construct and the choice of syntax is completely orthogonal to the purity of your functions. Kotlin is not a pure language and will never become one (due to JVM interop goals) and so any Kotlin syntactic construct allows you to call both pure and non-pure functions. So, programming with pure functions is a style issue in Kotlin — it is something you choose to do to improve your code, not something that is being enforced.

I think the issue here is declarative vs imperative and not purity

There is nothing imperative in

val x = ... ; val y = ... ; return ...

. It is a sequence of declarations, one building on another. Is it a

val

name that confuses people? You can call it

let

(like in Swift) when you read it, if it makes it more declarative for you

You can achieve imperative syntax with pure functions.

suspend

+ function application is still pure because

suspend

can't run without the continuation.

(suspend() -> A).invoke

is the same as

IO.flatMap

but not stack safe.

!

here is the same as

()

but stack safe.

val x: IO<Int> = fx {
  val n = !IO { 1 }
  val y = !IO { 1 }
  x + y
}

val x : IO<Int> = IO { 1 }.flatMap { n ->  IO { n + 1 } }

Kotlin is not a pure programming language. Kotlin function’s return type (unit/non-unit) is not related to the purity of the corresponding function or expression. It is considered good style in Kotlin to write mostly pure functions but it is not enforced in any way — it is up to developer to follow this practice.

Yes, we are not proposing this changes. The idea for the language proposal is that we enable that tracking locally with a compiler flag or experimental import feature because Kotlin is already doing side effect tracking with suspend. In whatever case my point is that imperative is unrelated to functions being pure because this is already pure:

suspend fun save(): Unit {
  doSave()
  etc()
}

Pure just means that when invoked it does not compile unless in IO or produces no effects. That is exactly what suspend does. It does not compile unless you have a continuation. We can't call that function directly on main or other places that are not suspended, that makes it pure and therefore is as valid as callback chains or wrappers for FP. FP style is fine with imperative style, what I believe is frowned upon is calling effects when the function ir not suspended or the datatypes like IO does not delay evaluation once it wraps the effect it is supposed to control.

@elizarov as for my concern: I agree that Kotlin is not a pure functional language and it shouldn't be one. My experience with Haskell is that forcing Functional everywhere creates as many problems as it solves, so I think the future will be to hybrid languages. Still I would find useful to mark pure functions, or bit of functions, as such. In the same way that you mark a suspendable function in Kotlin or a synchronized function in Java. The reasoning is kind of similar to the one about making a sealed class: you are protected from mis-use of your code. Since the compiler can verify that only pure calls are done inside a pure function, you can safely use some library calls knowing that you are not risking side-effects (where 90% of bugs stay). As for a silly example, the notorious SimpleDataFormat in Java is not thread safe because it is not immutable and there are several class in the jdk with similar problems. It would be nice for the compiler to verify if a method is pure/immutable/safe to use. Of course this is only my opinion, but for what it's worth I don't think it would betray the nature of the language having such a construct. Btw Haskell can be as imperative as you want with the do syntax so the issue is definitely not imperative vs declarative but pure vs impure.