Lawrence Job (Nov 20 2021 at 00:57): Lawrence Job (Nov 20 2021 at 00:57):Hi! Has anyone given any thought to how FRP would work in Roc?
I've seen two thoughts so far in my time in the repo:
1) Platform provided asynchronous behaviours (streams, etc)
2) Library provided observables (ReactiveX)
I come from a FRP background, and I'm curious to know if anyone has any ideas for how this might look in idiomatic Roc. I saw the nice pipe and backpassing syntax, and wonder if this could work.
A full reactive library would be a more elegant way to orchestrate async requests/effects by declaratively saying 'when this and this are both finished, fan in and combine the responses and make a subsequent call to another API while logging elsewhere'
I'm also really interested to learn about the multitasking behaviour in Roc but can't find it documented anywhere - is it platform-dependent?
Brendan Hansknecht (Nov 20 2021 at 01:04):I think this should be easy to do in roc (bar a few currently missing features). That being said, it would probably be completely built into the platform. I guess they would probably also add some wrapper roc code
Brendan Hansknecht (Nov 20 2021 at 01:05):Since roc is pure functional, it can essentially be called from anywhere in the platform without worrying about side effects.
Brendan Hansknecht (Nov 20 2021 at 01:05):So the platform really just needs to define the interface for roc to use. Could be TEA or something else
Brendan Hansknecht (Nov 20 2021 at 01:10):Also, async, multitasking, and parallel processing would all be platform dependent as well.
Brendan Hansknecht (Nov 20 2021 at 01:21):I guess one final note while I am still thinking about this, it will likely be common for platforms to use the same or similar primitives to get nice library support in roc.
For example if multiple platforms use the same async task primitive (or has a way to convert to said primitive), a roc library would be able to make a nice and consistent wrapper that can be used for all of the platforms.
Lawrence Job (Nov 20 2021 at 01:27):Thanks, that's insanely helpful
Lawrence Job (Nov 20 2021 at 01:30):It sounds like to be successful, a Task library needs a counterpart on both sides (platform+app), and then any library that wants to orchestrate tasks sits on top of that abstraction..
Brendan Hansknecht (Nov 20 2021 at 01:34):Yes. Also, as a note, the platform has to define its roc API and can define the task library on both sides.
Definitely look at some of the examples, they have various platform defined libraries, though most of them are quite simple and tasks are not really async. Though they could be redesigned to be.
Lawrence Job (Nov 20 2021 at 01:36):I saw some examples using fx.Effect but I can't seem to find where that pattern is established - possibly I'm too new and need to orient myself more
Brendan Hansknecht (Nov 20 2021 at 01:37):Ah, yeah, that should be in docs but probably isn't. Roc forces all calls to the platform to return an effect. Basically an abstraction to have managed effects as opposed to side effects.
Brendan Hansknecht (Nov 20 2021 at 01:38):On the platform side they are still just defining a function a -> b, but roc sees it as a -> effect b
Last updated: Jun 16 2026 at 16:19 UTC