redux-saga is a lot like an IO monad

Hello @yelouafi.

I’ve been thinking about how redux-saga has a lot in common with the IO monad from purely functional languages. But you’ve likely realized that as well. I’ve been using redux-saga for a project at work and I’m thoroughly enjoying it. But even though I can understand that it was inspired by the saga pattern I always think of it as an IO monad 😄

It occurred to me that the use of generators is reminiscent of Haskell’s do-notation. In fact Fantasy Do uses generator functions to implement do-notation for fantasy land monads.

I’ve played a little with the idea of implementing an IO-monad in JavaScript and using it with Fantasy Do like do-notation. Do you think such a thing is viable? One restriction would be that the do-notation would only allow one to yield IO-monad’s whereas redux-saga gives the user a lot of flexibility about what to yield.

I can see that there has previously (#16) been talk about decoupling redux-saga from redux. What is your thoughts about that now? I think a general purpose declarative effects library for JS could be interesting albeit probably not to an audience as wide as the Redux userbase.

[mxstbr]

and another concern is about maintaining 2 repos

You could go with a monorepo with the two packages in the same repo! That’d solve the issue problem

[paldepind]

Thanks for the great replies 😄

@slorber

I’ve often compared redux-saga to an hybrid between imperative programming and free monad.

The flow of redux-saga, often using while looks and sequential operations look like imperative programming, but the effects you can yield that are run against an interpreter look like the free monad. The difference between IO and Free is that with Free being that Free uses data structures and can be tested / transformed / interpreted while IO is more like a thunk that can only be run. See also: http://stackoverflow.com/a/34623840/82609

I have seen that you’ve mentioned the Free monad in other threads. It’s very interesting. I have been reading a bit about the Free monad. I don’t really understand it yet but I partly understand the similarity with redux-saga. In Haskell a function with the type Integer -> IO (String) conceptually returns a description of an action that produces a String when executed. In this sense it is very similar to redux-saga. But as you mention, the difference is that IO is completely opaque unlike saga actions that can be inspected and tested. If I understand correctly then Free accounts for this since it can be used to build up transparent AST structures that can be interpreted in several ways. But in the special case where the AST is simply executed it is similar to the IO monad. That is my current understanding. Please correct me if I’m wrong.

@yelouafi

But I’m not sure the IO monad models the effect as data concept (can be unit tested?). IO Seems like an opaque data type (although I don’t know how IO is tested in Haskell).

You are indeed right that IO is opaque, but conceptually it’s just data. I guess the reason for the opaqueness is so that it allows for IO-code to be compiled into efficient machine code where the IO construct doesn’t exist at run-time.

Testing IO code in Haskell is much like testing imperative JavaScript code: hard and messy 😭 It certainly doesn’t have the advantages that redux-saga has.

Another thing is related to concurrency, In redux-saga you can fork tasks in parallel, join and cancel them. Monads by nature are sequential. I think Haskell has a forkIO function but not sure how much control it gives over concurrency.

Monads are indeed sequential. But each line in a saga is also executed sequentially isn’t it? Line number 2 in a saga is never run before line number 1? It seems to me like it matches monads. I actually think the asynchronous features in redux-saga are covered by concurrency in the IO monad. fork in saga is like forkIO, call in saga is like a blocking IO action, cancel in saga is like killThread.

Generators have one limitation though: they can’t be started from an arbitrary point, this can cause weird problems when the monad calls the chain function multiple times (eg: Array monad), especially when chained blocks have visible side effects. Do Fantasy has a special multi mode to handle this.

Yes. That is a quite sad restriction. Especially because it breaks the abstraction in Fantasy Do. You can’t use the same do-notation with all monads. To solve this and other issues I’m working on a fantasy land replacement, jabz. I’m planning to specify it so that each monad must declare if it is multi or not. Then do-notation can be implemented so that it works for all monads and without the awkwardness in Fantasy Do.