haskell-zio

A small monad-transformer analogue to the Scala ZIO library (basically, UIO + Reader + Either/ExceptT).

I like to call ZIO a best-practices monad for applications. It wraps in a Reader monad for carrying around configuration and environment data, and slightly more controversially, makes error-handling more explicit by making all recoverable
exceptions and errors part of the return-type of functions.

Note that this is meant to provide the same basic functionality of the ZIO monad. While I'm not immediately looking into other features of ZIO-the-library, such as concurrency, I welcome suggestions via issues or pull requests.

Comparison to other Haskell libraries

• UIO This ZIO library builds upon UIO (Unexceptional-IO) as a dependency, and it is the inner-most monad in the transformer stack. We use UIO, in conjunction with ExceptT, to model possible error states (or the lack thereof) more explicitly. In other words, we are trying to make all errors or exceptions. checked exceptions, where possible. See the blog post (or backup) for more details.
• RIO integrates ReaderT with IO, but somewhat like Scala ZIO, provides much additional functionality, and providing much of that functionality
  will be a goal of haskell-zio as well.
• Trio has essentially the same goals as ZIO (and I believe it is isomorphic to ZIO), but is a self-described experiment at the moment. The major experimental aspect I'm aware of is that it is avoiding usage of ExceptT to improve performance, which I have not investigated. We are currently aiming for stability here, but ideally any code written for haskell-ZIO could easily be transferred to using Trio, or vice versa. If you see a difference, please raise an issue so we can document it or fix it.

The Scala-Haskell ZIO dictionary

Type Aliases

The Scala ZIO type parameters and aliases are largely reproduced in Haskell, though in some cases we can't exactly reproduce them. For instance, IO is already taken in Haskell at a very fundamental level. As well, UIO has the same meaning as in the Scala implementation, but it isn't an alias, since it is an inner monad of the ZIO type.

An apparent downsize of having UIO, EIO, and ZIO as distinct (non-aliased) types is that one might feel inclined to provide APIs for one or more of these when warranted. For this reason UEIO e, UZIO a, and other aliases along with associated lift and unlift functions are provided. These aliases have Void in the expanded type, and in some cases, it is more appropriate to use a universal quantifier, e.g., when lifting into a type, we usually have some Error type in mind other than Void (that's one big reason why we're using this library!), so we'd prefer to have e.g. uelift :: ∀ e a. UIO a -> EIO e a, not uelift :: UIO a -> UEIO a.