capability

Extensional capabilities and deriving combinators

https://github.com/tweag/capability

Version on this page:0.5.0.1@rev:1
LTS Haskell 21.25:0.5.0.1@rev:2
Stackage Nightly 2024-03-29:0.5.0.1@rev:3
Latest on Hackage:0.5.0.1@rev:3

See all snapshots capability appears in

BSD-3-Clause licensed
Maintained by [email protected]
This version can be pinned in stack with:capability-0.5.0.1@sha256:e69d6c2a61c28aefc0d6baa9358d0b34b2eb070d8999a10892bb87c3505796c6,3286

Module documentation for 0.5.0.1

capability: effects, extensionally

Build status

A capability is a type class that says explicitly which effects a function is allowed to use. The mtl works like this too. But unlike the mtl, this library decouples effects from their implementation. What this means in practice:

  • You can implement large sets of capabilities using the efficient ReaderT pattern, rather than a slow monad transformer stack.
  • Capabilities compose well: e.g. it’s easy to have multiple reader effects.
  • You can use a writer effect without implementing it as a writer monad (which is known to leak space).
  • You can reason about effects. For instance, if a monad provides a reader effect at type IORef A, it also provides a state effect at type A

For more on these, you may want to read the announcement blog post.

This library is an alternative to the mtl. It defines a set of standard, reusable capability type classes, such as the HasReader and HasState type classes, which provide the standard reader and state effects, respectively.

Where mtl instances only need to be defined once and for all, capability-style programming has traditionally suffered from verbose boilerplate: rote instance definitions for every new implementation of the capability. Fortunately GHC 8.6 introduced the DerivingVia language extension. We use it to remove the boilerplate, turning capability-style programming into an appealing alternative to mtl-style programming. The generic-lens library is used to access fields of structure in the style of the ReaderT pattern.

An additional benefit of separating capabilities from their implementation is that they avoid a pitfall of the mtl. In the mtl, two different MonadState are disambiguated by their types, which means that it is difficult to have two MonadState Int in the same monad stack. Capability type classes are parameterized by a name (also known as a tag). This makes it possible to combine multiple versions of the same capability. For example,

twoStates :: (HasState "a" Int m, HasState "b" Int m) => m ()

Here, the tags "a" and "b" refer to different state spaces.

In summary, compared to the mtl:

  • capabilities represent what effects a function can use, rather than how the monad is constructed;
  • capabilities are named, rather than disambiguated by type;
  • capabilites are discharged with deriving-via combinators and generic-lens, rather than with instance resolution.

An example usage looks like this:

testParity :: (HasReader "foo" Int m, HasState "bar" Bool m) => m ()
testParity = do
  num <- ask @"foo"
  put @"bar" (even num)

data Ctx = Ctx { foo :: Int, bar :: IORef Bool }
  deriving Generic

newtype M a = M { runM :: Ctx -> IO a }
  deriving (Functor, Applicative, Monad) via ReaderT Ctx IO
  -- Use DerivingVia to derive a HasReader instance.
  deriving (HasReader "foo" Int, HasSource "foo" Int) via
    -- Pick the field foo from the Ctx record in the ReaderT environment.
    Field "foo" "ctx" (MonadReader (ReaderT Ctx IO))
  -- Use DerivingVia to derive a HasState instance.
  deriving (HasState "bar" Bool, HasSource "bar" Bool, HasSink "bar" Bool) via
    -- Convert a reader of IORef to a state capability.
    ReaderIORef (Field "bar" "ctx" (MonadReader (ReaderT Ctx IO)))

example :: IO ()
example = do
    rEven <- newIORef False
    runM testParity (Ctx 2 rEven)
    readIORef rEven >>= print
    runM testParity (Ctx 3 rEven)
    readIORef rEven >>= print

For more complex examples, see the Examples section and the examples subtree.

API documentation can be found on Hackage.

Examples

An example is provided in WordCount. Execute the following commands to try it out:

$ nix-shell --pure --run "cabal configure --enable-tests"
$ nix-shell --pure --run "cabal repl examples"

ghci> :set -XOverloadedStrings
ghci> wordAndLetterCount "ab ba"
Letters
'a': 2
'b': 2
Words
"ab": 1
"ba": 1

To execute all examples and see if they produce the expected results run

$ nix-shell --pure --run "cabal test examples --show-details=streaming --test-option=--color"

Build instructions

Nix Shell

A development environment with all dependencies in scope is defined in shell.nix.

Build

The build instructions assume that you have Nix installed. Execute the following command to build the library.

$ nix-shell --pure --run "cabal configure"
$ nix-shell --pure --run "cabal build"

Changes

Revision history for capability

0.5.0.1 – 2022-03-21

0.5.0.0 – 2021-07-21

  • Fix compatibility with GHC 9.0. See #96

  • Remove Capability.Writer.Discouraged. This module incurred a dependency on monad-unlift which is no longer available for GHC 9.0. Given that its use was discouraged, it was deemed best to remove it. See #96

  • Added censor function to Capability.Writer. See #94

0.4.0.0 – 2021-03-15

  • Fix infinite loop in writer. See #85

  • Introduce Capability.Reflection to define ad-hoc interpreters. See #86

  • Fix compatibility with GHC 8.10. See #87

0.3.0.0 – 2020-03-19

  • Rename HasStream to HasSink, for symmetry. See #75

  • Introduce HasSource, a superclass of HasReader. See #75

  • Make HasSource and HasSink superclasses of HasState. See #75

  • Introduce derive to run an action that requires additional capabilities. See #74 and #83

  • Handlers zoom and magnify can now carry capabilities over from the context. See #73

  • Introduce functional capabilities and the TypeOf type family. See #72

0.2.0.0 – 2019-03-22

  • Make HasStream a superclass of HasWriter. See #64
  • Bumped version bounds on generic-lens. See #67

0.1.0.0 – 2018-10-04

  • Initial release.