Stream: ideas

Topic: dedicated TCP platform

view this post on Zulip Anton (Mar 30 2024 at 18:21):

For a potential book chapter we'd need to able to receive TCP connections. This does not seem to fit with any current platforms and I think a dedicated TCP platform makes sense in general. What do you think?

view this post on Zulip Norbert Hajagos (Mar 30 2024 at 19:40):

When I brought it up, ppl seemed to favor basic-cli implementing it. Richard've said he has found cases where it would be helpful:

view this post on Zulip Luke Boswell (Apr 01 2024 at 01:03):

I'm not sure about the API. I've had a bit of a look, and it's not clear what we want to pass from roc across to the host (rust) to handle each of the incoming connections, and/or how to close it and continue to exit the program.

At the moment basic-cli runs through each task through to completion. mainForHost : Task {} I32 provides a task to the platform.

If one of those effects opens and listens on a TCP socket for connections; can we provide a handler for the host?

I'm not sure how to do that without changing the signature of mainForHost, as we now have the host needing to call into roc and not the other way around. So maybe we need to change the signature to something like;

mainForHost : {
    main : Task {} I32,
    tcpHandler: [Nothing, WithHandler (Stream -> Task {} I32)],
}

view this post on Zulip Luke Boswell (Apr 01 2024 at 01:03):

Or maybe we can have an effect which "sets" the handler? something like setTcpHandler : (Stream -> Task [KeepListening state, Done state] I32) -> Task {} I32? and then when we start listening tcpListen: Task state [TcpErrors] we use that handler (if it was set) and when it returns Done state we return back to roc. Where state here is provided from the app to the platform.

Last updated: Jun 16 2026 at 16:19 UTC