Introduce a "sending side" (settable) for Deferred

[elizarov]

As reported by @vaskir at public Slack:

What if I want to pass it as a channel somewhere, then wait until it's ready? I do it with a channel like this:

    val reply = Channel<Long>()
    getAndResetCh.send(reply)
    return reply.receive()
}

so I send a message to an actor "do the job, then send the result to this channel when ready", then I wait on receive asynchronously.

So, the use-case is basically to send some object to remote actor to receive a single answer from it. How to we name such and object and what would its "sending" (setting) function be named?

[vasily-kirichenko]

The idea is from CML (Concurrent ML) and its port to .NET - Hopac, see https://github.com/Hopac/Hopac/blob/master/Docs/Internals.md#non-selective-synchronous-message-passing-primitives

So, in Kotlin we could make it like this:

interface Var<T> {
    companion object {
        fun <T> createFilled(value: T) { ... }
    }

    suspend fun fill(value: T) {
        if (isEmpty) ...
        else throw Exception("Cannot fill a full variable")
    }

    suspend fun read() : T = ...
}

usage:

class DoJob(val reply: Var<Int>)

fun test() = runBlocking {
    val a = actor<DoJob>(CommonPool) {
        for (msg in channel)
            msg.reply.fill(22)
    }

    val reply = Var<Int>()
    a.send(DoJob(reply))
    println("Result = ${reply.read()}")
    
    val v = Var.createFilled(22)
}

Also something like

public fun <E> Var<E>.onReceive(block: suspend (E) -> R)

should be added to SelectBuilder (or we could extract a new interface ReceiveChannel and Var would conform to; or make Var : ReceiveChannel), because it must be usable inside select.

[elizarov]

Thanks for the pointer. On "receiving" side we already have Deferred with await suspending function and onAwait clause for select expression. So, all is left is to figure out naming for "sending" (setting/filling) side of it.

[vasily-kirichenko]

Ah, I see. Cool :) Maybe get and set is better, I dunno.

[vasily-kirichenko]

I recall another thing about IVars - they can hold either a value or an exception. To fill it with the latter, there is fillFailure function. As a result, await and onAwait should throw that exception. I'm not sure if such behavior would fit nicely to coroutines design though.

[elizarov]

Get/set are actually not ideal, especially get, since this verb does not imply the await. That was the reason for using await as a verb for receiving side. The short list of verbs for the other side that I come with:

• fill
• fulfill
• complete
• resolve

[vasily-kirichenko]

CML uses iPut:

I think fill is the best.

[vasily-kirichenko]

Haskell uses put http://hackage.haskell.org/package/monad-par-0.3.4.4/docs/Control-Monad-Par.html#g:2

[elizarov]

@vasily-kirichenko Yes. That is how Deferred works, too. It either holds value or exception and await throws it. It is not an innovation, since every future/promise/deferred implementation in exception-capable language that I know of works in the same way.

It means that when pick a verb xxx we'll also have a paired xxxWithExceptoin or xxxExceptionally.

[elizarov]

I'm inclining to introduce a class named Completable<T> that implements Deferred<T> and has the following two functions:

fun complete(value: T): Boolean
fun completeWithException(exception: Throwable): Boolean

Both functions return false when invoked on an already completed instance.

[elizarov]

The downside is that Rx also uses Completable and gives a different meaning. I wonder if an equally good alternative name can be found. However, the complete verb is the best match to the existing documentation of Deferred.

[fvasco]

CompletableDeferred?

Looks like a Future and CompletableFuture.

Also like to List (Deferred) and MutableList (CompletableDeferred).

[elizarov]

@fvasco CompletableDeferred is a good name for the purposes you've outlined, even though it is slightly too wordy. It would be often be used as the "result" type when communicating with actors. Your typical actor request class would look like:

class DoSomethingRequest(val param: Param, val result: CompletableDeferred<Result>)

I wonder if its name can be made shorter while keeping the same level of clarity on what it does.

[elizarov]

Here's draft implementation: https://github.com/Kotlin/kotlinx.coroutines/blob/7a3afb54900d565ff5943e02220d45f1b96589ab/kotlinx-coroutines-core/src/main/kotlin/kotlinx/coroutines/experimental/CompletableDeferred.kt

[vasily-kirichenko]

Looks good, but the name is indeed too long.