Idea: defer(Executor) about sodium HOT 15 CLOSED

Thanks for all these questions. It's great! Can you give me a bit more information about onExecutor? Where do I find the code for it?

Would you like to check your kotlin version into the Sodium repo? I've invited you as a member of the project.

from sodium.

Like original defer, but executes transaction on executor.

    override fun defer(executor: Executor): StreamImpl<A> {
        val out = StreamWithSend<A>()

        val listener = Transaction.apply2 {
            listen(it, out.node) { trans2, value ->
                executor.execute {
                    Transaction.apply2 {
                        out.send(it, value)
                    }
                }
            }
        }

        return out.addCleanup(listener)
    }

from sodium.

1. This is different to defer, because defer makes a guarantee that the new transaction will occur before any other event. This introduces non-determinism, and a lot of the point of FRP and functional programming is to get rid of non-determinism.
2. Threads are not part of the FRP paradigm. What thread things run on is an operational issue, and doesn't belong in an FRP API - at least, not in that form.
3. A similiar primitive to your one that could be thought of as a "perform IO" primitive would be useful.

from sodium.

I understood. You right. From this point of view it would be better to add listen(Executor, (Event<A>) -> Unit). It turns out that IO is stop-point for FRP computations. This sad because my code has a lot of such places.

We must figure out how identify such sections. How I must use functions like onExecutor?

clicked().io().map().io().listen(...)

Operational.io(Operational.io(clicked()).map()).listen(...)

val io1 = streamSink()
val io2 = streamSink()
clicked().io(io1)
io1.map().io(io2)
io2.listen(...)

from sodium.

The first one is nicest. I am aware that we should add more helpers to Sodium, but I really want them to be kept to an absolute minimum. So we can add them after much discussion and thought.

from sodium.

More explaination: the io function is abstract io operation, for axample onExecutor or queryFromHttp

The first example looks nice, but syntax of io oparations does not differ from true FRP primitives. It is bad. What if such function accidentally occures in true FRP flow? The code can become broken, and we dont even know why.

The io operations must be stoppers like listen. Thats why i like third example.

from sodium.

Or may be io operations must just return Stream<Stream<A>>?

from sodium.

Yes. Also remember that even though it would make the user's code nicer, the FRP system doesn't really need this helper. The user could just figure out their own way of doing it using StreamSink, listen and addCleanup.

from sodium.

I'm assuming an IO operation is a function from Stream<A> to Stream<B>. For each request of type A there's a response of type B, but they could be interleaved.

from sodium.

clicked().flatMap { io1() }.map().flatMap { io2() }.listen()

But here we have buggy flatMap from antother issue.

from sodium.

io2(io1(clicked()).map(...)).listen()

from sodium.

class IO<A> : () -> A

fun Stream<Unit>.io1(): Stream<IO<String>>
fun Stream<IO<String>>.io2(): Stream<IO<Int>>

clicked().io1().ioMap(...).io2().ioListen(...)

from sodium.

Maybe one day Java will have extension methods!

from sodium.

Thats why I use kotlin.

from sodium.

That's why I use Haskell.

from sodium.