An easy to use, performant extensible effects library with seamless integration with the existing Haskell ecosystem.
Go to file
2022-05-29 04:49:34 +02:00
.github/workflows Test with GHC 9.2.2 2022-03-07 21:17:21 +01:00
benchmarks One more reword 2022-03-29 23:55:57 +02:00
effectful Rename dynamic state runners to match the module hierarchy 2022-05-29 04:49:34 +02:00
effectful-core Rename dynamic state runners to match the module hierarchy 2022-05-29 04:49:34 +02:00
effectful-th Allow template-haskell-2.19 and restrict version of th-abstraction 2022-05-28 08:56:12 +02:00
.gitignore .gitignore fix for Stack configurations (#12) 2021-07-01 11:00:01 +02:00
cabal.haskell-ci Update CI 2021-12-09 20:16:42 +01:00
cabal.project Add effectful-th based on the code from cleff (#60) 2022-02-22 21:39:14 +01:00
CHANGELOG.md Change name to effectful 2021-06-13 20:08:33 +02:00
doctest.sh Add effectful-th based on the code from cleff (#60) 2022-02-22 21:39:14 +01:00
LICENSE Document dynamic variants of basic effects 2022-01-25 10:21:24 +01:00
README.md Clarification 2022-05-27 22:05:05 +02:00
transformers.md Reduce usage of 'very' 2022-05-27 06:01:17 +02:00

effectful

Build Status Documentation Documentation

Note: this is a pre-release of the 0.1 version. Please disregard the 0.0.0.0 version available on Hackage as the API has been completely redesigned since then.

An easy to use, fast extensible effects library with seamless integration with the existing Haskell ecosystem.

Main features:

  1. Very fast (benchmarks).

  2. Easy to use API (if you know how to use the MonadUnliftIO class, you know how to write effects).

  3. Correct semantics in presence of runtime exceptions (no more discarded state updates).

  4. Seamless integration with the existing ecosystem (exceptions, monad-control, unliftio-core, resourcet etc.).

  5. Support for thread local and shared state (e.g. StateT provides a thread local state, while MVar holds a shared state, both approaches have their merits).

  6. Support for statically (implementation determined at compile time) and dynamically (implementation determined at run time) dispatched effects.

Motivation

Do we really need yet another library for handling effects? There's freer-simple, fused-effects, polysemy, eff and probably a few more.

Unfortunately, of all of them only eff is a promising proposition because of reasonable performance characteristics (see the talk "Effects for Less" linked below for more information) and potential for good interoperability with the existing ecosystem.

The second point is arguably the most important, because it allows focusing on things that matter instead of reinventing all kinds of wheels, hence being a necessary condition for broader adoption of the library.

However, eff uses delimited continuations underneath, which:

  • Are not yet supported by GHC (though the proposal for including support for them has been accepted).

  • Are quite hard to understand.

  • Make the library "too powerful" in a sense as it faces a few issues with no clear path towards their resolution.

What about mtl?

It's true that its "effects as classes" approach is widely known and used often.

However:

  • mtl style effects are slow.

  • All of most often used monad transformers (except ReaderT) used for effect implementations are rife with subtle issues.

These issues are problematic enough that the ReaderT design pattern was invented. Its fundamentals are solid, but it's not an effect system.

The solution? Use the ReaderT pattern as a base and build around it to make it an effect system! This is where effectful comes in. The Eff monad it uses is essentially a ReaderT over IO on steroids, allowing us to dynamically extend its environment with data types representing effects.

This concept is quite simple, so:

  • It's reasonably easy to understand what is going on under the hood.

  • The Eff monad being a reader allows for seamless interoperability with ubiquitous classes such as MonadBaseControl and MonadUnliftIO and solves issues of monad transformers mentioned above.

What is more, the Eff monad is concrete, so GHC has many possibilities for optimization, which results in a very fast code at a default optimization level. There is no need to mark every function INLINE or enable additional optimization passes, it just works.

Any downsides?

As always, there's no free lunch. Eff doesn't support NonDet nor Coroutine effects. However, the NonDet effect in existing libraries is broken and none of the ones with support for higher order effects provide the Coroutine effect, so arguably it's not a big loss.

If you need such capability in your application, there are well established libraries such as conduit or list-t that can be used with effectful without any issues.

Summary

effectful aims to replace "boring" transformer stacks (which 99% of time consist of a dozen of newtype'd ExceptT, ReaderT, StateT and WriterT transformers) by providing equivalent effects with much improved semantics, performance and usability. It doesn't try to make monad transformers obsolete, so you're free to use it with ConduitT, ContT, ListT etc. when necessary.

Usage

The effect system is split among several libraries:

  • The effectful-core library contains the main machinery of the effect system itself and basic effects. It aims for a small dependency footprint and provides building blocks for more advanced effects.

  • The effectful-th library provides utilities for generating bits of effect-related boilerplate via Template Haskell.

  • The effectful library re-exports public modules of effectful-core and additionally provides most features of the unliftio library divided into appropriate effects.

Example

A Filesystem effect with two handlers, one that runs in IO and another that uses an in-memory virtual file system can be found here.

Resources

Resources that inspired the rise of this library and had a lot of impact on its design.

Talks:

Blog posts:


Icons made by Freepik from www.flaticon.com