Documentation

Transform an Embed m effect into a Final m effect

Since: polysemy-1.2.0.0

Lower a Sem containing only a single lifted, final Monad into that monad.

If you also need to process an Embed m effect, use this together with embedToFinal.

Since: polysemy-1.2.0.0

withWeavingToFinal admits an implementation of embed.

Just like embed, you are discouraged from using this in application code.

Since: polysemy-1.2.0.0

An effect for embedding higher-order actions in the final target monad of the effect stack.

This is very useful for writing interpreters that interpret higher-order effects in terms of the final monad.

Final is more powerful than Embed, but is also less flexible to interpret (compare runEmbedded with finalToFinal). If you only need the power of embed, then you should use Embed instead.

Beware: Final actions are interpreted as actions of the final monad, and the effectful state visible to withWeavingToFinal / withStrategicToFinal / interpretFinal is that of all interpreters run in order to produce the final monad.

This means that any interpreter built using Final will not respect local/global state semantics based on the order of interpreters run. You should signal interpreters that make use of Final by adding a -Final suffix to the names of these.

State semantics of effects that are not interpreted in terms of the final monad will always appear local to effects that are interpreted in terms of the final monad.

State semantics between effects that are interpreted in terms of the final monad depend on the final monad. For example, if the final monad is a monad transformer stack, then state semantics will depend on the order monad transformers are stacked.

Since: polysemy-1.2.0.0

Transform an effect e1 into an effect e2 that is already somewhere inside of the stack.

Since: polysemy-1.2.3.0

Rewrite an effect e1 directly into e2, and put it on the top of the effect stack.

Since: polysemy-1.2.3.0

Like intercept, but for higher-order effects.

See the notes on Tactical for how to use this function.

Like interpret, but instead of handling the effect, allows responding to the effect while leaving it unhandled. This allows you, for example, to intercept other effects and insert logic around them.

Like reinterpret, but introduces three intermediary effects.

Like reinterpret3, but for higher-order effects.

See the notes on Tactical for how to use this function.

Like reinterpret, but introduces two intermediary effects.

Like reinterpret2, but for higher-order effects.

See the notes on Tactical for how to use this function.

Like interpret, but instead of removing the effect e, reencodes it in some new effect f. This function will fuse when followed by runState, meaning it's free to reinterpret in terms of the State effect and immediately run it.

Like reinterpret, but for higher-order effects.

See the notes on Tactical for how to use this function.

Like interpret, but for higher-order effects (ie. those which make use of the m parameter.)

See the notes on Tactical for how to use this function.

The simplest way to produce an effect handler. Interprets an effect e by transforming it into other effects inside of r.

Run an effect stack all the way down to IO by running it in a new thread, and temporarily turning the current thread into an event poll.

This function creates a thread, and so should be compiled with -threaded.

Since: polysemy-0.5.0.0

Like makeSem, but does not provide type signatures and fixities. This can be used to attach Haddock comments to individual arguments for each generated function.

data Output o m a where
  Output :: o -> Output o m ()

makeSem_ ''Output

-- | Output the value @o@.
output :: forall o r
       .  Member (Output o) r
       => o         -- ^ Value to output.
       -> Sem r ()  -- ^ No result.

Because of limitations in Template Haskell, signatures have to follow some rules to work properly:

• makeSem_ must be used before the explicit type signatures
• signatures have to specify argument of Sem representing union of effects as r (e.g. Sem r ())
• all arguments in effect's type constructor have to follow naming scheme from data constructor's declaration:

data Foo e m a where
  FooC1 :: Foo x m ()
  FooC2 :: Foo (Maybe x) m ()

should have x in type signature of fooC1:

fooC1 :: forall x r. Member (Foo x) r => Sem r ()

and Maybe x in signature of fooC2:

fooC2 :: forall x r. Member (Foo (Maybe x)) r => Sem r ()

• all effect's type variables and r have to be explicitly quantified using forall (order is not important)

These restrictions may be removed in the future, depending on changes to the compiler.

Change in (TODO(Sandy): version): in case of GADTs, signatures now only use names from data constructor's type and not from type constructor declaration.

Since: polysemy-0.1.2.0

If T is a GADT representing an effect algebra, as described in the module documentation for Polysemy, $(makeSem ''T) automatically generates a smart constructor for every data constructor of T. This also works for data family instances. Names of smart constructors are created by changing first letter to lowercase or removing prefix : in case of operators. Fixity declaration is preserved for both normal names and operators.

Since: polysemy-0.1.2.0

Lift a kleisli action into the stateful environment. You can use bindTSimple to execute an effect parameter of the form a -> m b by providing the result of a runTSimple or another bindTSimple.

This is a less flexible but significantly simpler variant of bindT. Instead of returning a Sem kleisli action corresponding to the provided kleisli action, bindTSimple runs the kleisli action immediately.

Since: polysemy-1.5.0.0

Lift a kleisli action into the stateful environment. You can use bindT to get an effect parameter of the form a -> m b into something that can be used after calling runT on an effect parameter m a.

Run a monadic action in a Tactical environment. The stateful environment used will be the same one that the effect is initally run in. Use bindTSimple if you'd prefer to explicitly manage your stateful environment.

This is a less flexible but significantly simpler variant of runT. Instead of returning a Sem action corresponding to the provided action, runTSimple runs the action immediately.

Since: polysemy-1.5.0.0

Run a monadic action in a Tactical environment. The stateful environment used will be the same one that the effect is initally run in. Use bindT if you'd prefer to explicitly manage your stateful environment.

Lift a value into Tactical.

Get a natural transformation capable of potentially inspecting values inside of f. Binding the result of getInspectorT produces a function that can sometimes peek inside values returned by bindT.

This is often useful for running callback functions that are not managed by polysemy code.

Example

We can use the result of getInspectorT to "undo" pureT (or any of the other Tactical functions):

ins <- getInspectorT
fa <- pureT "hello"
fb <- pureT True
let a = inspect ins fa   -- Just "hello"
    b = inspect ins fb   -- Just True

Get the stateful environment of the world at the moment the effect e is to be run. Prefer pureT, runT or bindT instead of using this function directly.

Tactical is an environment in which you're capable of explicitly threading higher-order effect states. This is provided by the (internal) effect Tactics, which is capable of rewriting monadic actions so they run in the correct stateful environment.

Inside a Tactical, you're capable of running pureT, runT and bindT which are the main tools for rewriting monadic stateful environments.

For example, consider trying to write an interpreter for Resource, whose effect is defined as:

data Resource m a where
  Bracket :: m a -> (a -> m ()) -> (a -> m b) -> Resource m b

Here we have an m a which clearly needs to be run first, and then subsequently call the a -> m () and a -> m b arguments. In a Tactical environment, we can write the threading code thusly:

Bracket alloc dealloc use -> do
  alloc'   <- runT  alloc
  dealloc' <- bindT dealloc
  use'     <- bindT use

where

alloc'   ::         Sem (Resource ': r) (f a1)
dealloc' :: f a1 -> Sem (Resource ': r) (f ())
use'     :: f a1 -> Sem (Resource ': r) (f x)

The f type here is existential and corresponds to "whatever state the other effects want to keep track of." f is always a Functor.

alloc', dealloc' and use' are now in a form that can be easily consumed by your interpreter. At this point, simply bind them in the desired order and continue on your merry way.

We can see from the types of dealloc' and use' that since they both consume a f a1, they must run in the same stateful environment. This means, for illustration, any puts run inside the use block will not be visible inside of the dealloc block.

Power users may explicitly use getInitialStateT and bindT to construct whatever data flow they'd like; although this is usually unnecessary.

A container for inspect. See the documentation for getInspectorT.

Like .@, but for interpreters which change the resulting type --- eg. lowerError.

Some interpreters need to be able to lower down to the base monad (often IO) in order to function properly --- some good examples of this are lowerError and lowerResource.

However, these interpreters don't compose particularly nicely; for example, to run lowerResource, you must write:

runM . lowerError runM

Notice that runM is duplicated in two places here. The situation gets exponentially worse the more intepreters you have that need to run in this pattern.

Instead, .@ performs the composition we'd like. The above can be written as

(runM .@ lowerError)

The parentheses here are important; without them you'll run into operator precedence errors.

Warning: This combinator will duplicate work that is intended to be just for initialization. This can result in rather surprising behavior. For a version of .@ that won't duplicate work, see the .@! operator in polysemy-zoo.

Interpreters using Final may be composed normally, and avoid the work duplication issue. For that reason, you're encouraged to use -Final interpreters instead of lower- interpreters whenever possible.

Lower a Sem containing only a single lifted Monad into that monad.

Embed a monadic action m in Sem.

Since: polysemy-1.0.0.0

Introduce a set of effects into Sem at the index i, before the effect that previously occupied that position. This is intended to be used with a type application:

let
  sem1 :: Sem [e1, e2, e3, e4, e5] a
  sem1 = insertAt @2 (sem0 :: Sem [e1, e2, e5] a)

Since: polysemy-1.6.0.0

Interprets an effect in terms of another identical effect.

This is useful for defining interpreters that use reinterpretH without immediately consuming the newly introduced effect. Using such an interpreter recursively may result in duplicate effects, which may then be eliminated using subsume.

For a version that can introduce an arbitrary number of new effects and reorder existing ones, see subsume_.

Since: polysemy-1.2.0.0

Allows reordering and adding known effects on top of the effect stack, as long as the polymorphic "tail" of new stack is a raise-d version of the original one. This function is highly polymorphic, so it may be a good idea to use its more concrete version (subsume), fitting functions from the raise family or type annotations to avoid vague errors in ambiguous contexts.

Since: polysemy-1.4.0.0

Like raise, but introduces an effect three levels underneath the head of the list.

Since: polysemy-1.4.0.0

Like raise, but introduces an effect two levels underneath the head of the list.

Since: polysemy-1.4.0.0

Like raise, but introduces three new effects underneath the head of the list.

Since: polysemy-1.2.0.0

Like raise, but introduces two new effects underneath the head of the list.

Since: polysemy-1.2.0.0

Like raise, but introduces a new effect underneath the head of the list. See raiseUnder2 or raiseUnder3 for introducing more effects. If you need to introduce even more of them, check out subsume_.

raiseUnder can be used in order to turn transformative interpreters into reinterpreters. This is especially useful if you're writing an interpreter which introduces an intermediary effect, and then want to use an existing interpreter on that effect.

For example, given:

fooToBar :: Member Bar r => Sem (Foo ': r) a -> Sem r a
runBar   :: Sem (Bar ': r) a -> Sem r a

You can write:

runFoo :: Sem (Foo ': r) a -> Sem r a
runFoo =
    runBar     -- Consume Bar
  . fooToBar   -- Interpret Foo in terms of the new Bar
  . raiseUnder -- Introduces Bar under Foo

Since: polysemy-1.2.0.0

Introduce an effect into Sem. Analogous to lift in the mtl ecosystem. For a variant that can introduce an arbitrary number of effects, see raise_.

Introduce an arbitrary number of effects on top of the effect stack. This function is highly polymorphic, so it may be good idea to use its more concrete versions (like raise) or type annotations to avoid vague errors in ambiguous contexts.

Since: polysemy-1.4.0.0

Makes constraints of functions that use multiple effects shorter by translating single list of effects into multiple Member constraints:

foo :: Members '[ Output Int
                , Output Bool
                , State String
                ] r
    => Sem r ()

translates into:

foo :: ( Member (Output Int) r
       , Member (Output Bool) r
       , Member (State String) r
       )
    => Sem r ()

Since: polysemy-0.1.2.0

Type synonym for interpreters that consume an effect without changing the return value. Offered for user convenience.

r Is kept polymorphic so it's possible to place constraints upon it:

teletypeToIO :: Member (Embed IO) r
             => InterpreterFor Teletype r

Variant of InterpreterFor that takes a list of effects. @since 1.5.0.0

A proof that the effect e is available somewhere inside of the effect stack r.

Like Member, but will produce an error message if the types are ambiguous. This is the constraint used for actions generated by makeSem.

Be careful with this. Due to quirks of TypeError, the custom error messages emitted by this can potentially override other, more helpful error messages. See the discussion in Issue #227.

Since: polysemy-1.2.3.0

The Sem monad handles computations of arbitrary extensible effects. A value of type Sem r describes a program with the capabilities of r. For best results, r should always be kept polymorphic, but you can add capabilities via the Member constraint.

The value of the Sem monad is that it allows you to write programs against a set of effects without a predefined meaning, and provide that meaning later. For example, unlike with mtl, you can decide to interpret an Error effect traditionally as an Either, or instead as (a significantly faster) IO Exception. These interpretations (and others that you might add) may be used interchangeably without needing to write any newtypes or Monad instances. The only change needed to swap interpretations is to change a call from runError to errorToIOFinal.

The effect stack r can contain arbitrary other monads inside of it. These monads are lifted into effects via the Embed effect. Monadic values can be lifted into a Sem via embed.

Higher-order actions of another monad can be lifted into higher-order actions of Sem via the Final effect, which is more powerful than Embed, but also less flexible to interpret.

A Sem can be interpreted as a pure value (via run) or as any traditional Monad (via runM or runFinal). Each effect E comes equipped with some interpreters of the form:

runE :: Sem (E ': r) a -> Sem r a

which is responsible for removing the effect E from the effect stack. It is the order in which you call the interpreters that determines the monomorphic representation of the r parameter.

Order of interpreters can be important - it determines behaviour of effects that manipulate state or change control flow. For example, when interpreting this action:

>>> :{
  example :: Members '[State String, Error String] r => Sem r String
  example = do
    put "start"
    let throwing, catching :: Members '[State String, Error String] r => Sem r String
        throwing = do
          modify (++"-throw")
          throw "error"
          get
        catching = do
          modify (++"-catch")
          get
    catch @String throwing (\ _ -> catching)
:}

when handling Error first, state is preserved after error occurs:

>>> :{
  example
    & runError
    & fmap (either id id)
    & evalState ""
    & runM
    & (print =<<)
:}
"start-throw-catch"

while handling State first discards state in such cases:

>>> :{
  example
    & evalState ""
    & runError
    & fmap (either id id)
    & runM
    & (print =<<)
:}
"start-catch"

A good rule of thumb is to handle effects which should have "global" behaviour over other effects later in the chain.

After all of your effects are handled, you'll be left with either a Sem '[] a, a Sem '[ Embed m ] a, or a Sem '[ Final m ] a value, which can be consumed respectively by run, runM, and runFinal.

Examples

As an example of keeping r polymorphic, we can consider the type

Member (State String) r => Sem r ()

to be a program with access to

get :: Sem r String
put :: String -> Sem r ()

methods.

By also adding a

Member (Error Bool) r

constraint on r, we gain access to the

throw :: Bool -> Sem r a
catch :: Sem r a -> (Bool -> Sem r a) -> Sem r a

functions as well.

In this sense, a Member (State s) r constraint is analogous to mtl's MonadState s m and should be thought of as such. However, unlike mtl, a Sem monad may have an arbitrary number of the same effect.

For example, we can write a Sem program which can output either Ints or Bools:

foo :: ( Member (Output Int) r
       , Member (Output Bool) r
       )
    => Sem r ()
foo = do
  output @Int  5
  output True

Notice that we must use -XTypeApplications to specify that we'd like to use the (Output Int) effect.

Since: polysemy-0.1.2.0

The kind of effects.

Since: polysemy-0.5.0.0

The kind of effect rows.

Since: polysemy-0.5.0.0

An effect which allows a regular Monad m into the Sem ecosystem. Monadic actions in m can be lifted into Sem via embed.

For example, you can use this effect to lift IO actions directly into Sem:

embed (putStrLn "hello") :: Member (Embed IO) r => Sem r ()

That being said, you lose out on a significant amount of the benefits of Sem by using embed directly in application code; doing so will tie your application code directly to the underlying monad, and prevent you from interpreting it differently. For best results, only use Embed in your effect interpreters.

Consider using trace and traceToIO as a substitute for using putStrLn directly.

Since: polysemy-1.0.0.0

Run an Async effect in terms of async.

Since: polysemy-1.0.0.0

Run an Async effect in terms of async through final IO.

Beware: Effects that aren't interpreted in terms of IO will have local state semantics in regards to Async effects interpreted this way. See Final.

Notably, unlike asyncToIO, this is not consistent with State unless runStateIORef is used. State that seems like it should be threaded globally throughout Async will not be.

Use asyncToIO instead if you need to run pure, stateful interpreters after the interpreter for Async. (Pure interpreters are interpreters that aren't expressed in terms of another effect or monad; for example, runState.)

Since: polysemy-1.2.0.0

A more flexible --- though less performant --- version of asyncToIOFinal.

This function is capable of running Async effects anywhere within an effect stack, without relying on Final to lower it into IO. Notably, this means that State effects will be consistent in the presence of Async.

asyncToIO is unsafe if you're using await inside higher-order actions of other effects interpreted after Async. See Issue #205.

Prefer asyncToIOFinal unless you need to run pure, stateful interpreters after the interpreter for Async. (Pure interpreters are interpreters that aren't expressed in terms of another effect or monad; for example, runState.)

Since: polysemy-1.0.0.0

Perform a sequence of effectful actions concurrently.

Since: polysemy-1.2.2.0

An effect for spawning asynchronous computations.

The Maybe returned by async is due to the fact that we can't be sure an Error effect didn't fail locally.

Since: polysemy-0.5.0.0

Transform an AtomicState effect to a State effect, discarding the notion of atomicity.

Run an AtomicState effect in terms of atomic operations in IO.

Internally, this simply creates a new IORef, passes it to runAtomicStateIORef, and then returns the result and the final value of the IORef.

Beware: As this uses an IORef internally, all other effects will have local state semantics in regards to AtomicState effects interpreted this way. For example, throw and catch will never revert atomicModifys, even if runError is used after atomicStateToIO.

Since: polysemy-1.2.0.0

Run an AtomicState effect by transforming it into atomic operations over a TVar.

Run an AtomicState effect by transforming it into atomic operations over an IORef.

A variant of atomicModify in which the computation is strict in the new state.

A variant of atomicState in which the computation is strict in the new state and return value.

Since: polysemy-1.2.2.0

Atomically reads and modifies the state.

A variant of State that supports atomic operations.

Since: polysemy-1.1.0.0

Run an Error effect as an IO Exception. This interpretation is significantly faster than runError, at the cost of being less flexible.

Since: polysemy-1.0.0.0

Run an Error effect as an IO Exception through final IO. This interpretation is significantly faster than runError.

Beware: Effects that aren't interpreted in terms of IO will have local state semantics in regards to Error effects interpreted this way. See Final.

Since: polysemy-1.2.0.0

Transform one Error into another. This function can be used to aggregate multiple errors into a single type.

Since: polysemy-1.0.0.0

Run an Error effect in the style of ExceptT.

The function catchJust is like catch, but it takes an extra argument which is an exception predicate, a function which selects which type of exceptions we're interested in.

A variant of try that takes an exception predicate to select which exceptions are caught (c.f. catchJust). If the exception does not match the predicate, it is re-thrown.

Similar to catch, but returns an Either result which is (Right a) if no exception of type e was thrown, or (Left ex) if an exception of type e was thrown and its value is ex.

Attempt to extract a Just a from a Maybe a, throwing the provided exception upon Nothing.

Like fromExceptionSem, but with the ability to transform the exception before turning it into an Error.

Run a Sem r action, converting any IO exception generated by it into an Error.

Like fromException, but with the ability to transform the exception before turning it into an Error.

Lift an exception generated from an IO action into an Error.

A combinator doing embed and fromEither at the same time. Useful for interoperating with IO.

Since: polysemy-0.5.1.0

Upgrade an Either into an Error effect.

Since: polysemy-0.5.1.0

Run a Fail effect in terms of an underlying MonadFail instance.

Transform a Fail effect into a NonDet effect, through mapping any failure to empty.

Transform a Fail effect into an Error e effect, through providing a function for transforming any failure to an exception.

Run a Fail effect purely.

Runs an Input effect by evaluating a monadic action for each request.

Run an Input effect by providing a different element of a list each time. Returns Nothing after the list is exhausted.

Run an Input effect by always giving back the same value.

Apply a function to an input, cf. asks

An effect which can provide input to an application. Useful for dealing with streaming input.

Runs an Output effect by running a monadic action for each of its values.

Accumulate outputs so they are delayed until they reach at least size size.

If size is 0, this interpretation will not emit anything in the resulting Output effect.

Since: polysemy-1.0.0.0

Run an Output effect by ignoring it.

Since: polysemy-1.0.0.0

Like outputToIOMonoid, but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of outputToIOMonoid if the monoid is a list, such as String.

Beware: As this uses an IORef internally, all other effects will have local state semantics in regards to Output effects interpreted this way. For example, throw and catch will never revert outputs, even if runError is used after outputToIOMonoidAssocR.

Since: polysemy-1.2.0.0

Run an Output effect in terms of atomic operations in IO.

Internally, this simply creates a new IORef, passes it to runOutputMonoidIORef, and then returns the result and the final value of the IORef.

Beware: As this uses an IORef internally, all other effects will have local state semantics in regards to Output effects interpreted this way. For example, throw and catch will never revert outputs, even if runError is used after outputToIOMonoid.

Since: polysemy-1.2.0.0

Run an Output effect by transforming it into atomic operations over a TVar.

Since: polysemy-1.1.0.0

Run an Output effect by transforming it into atomic operations over an IORef.

Since: polysemy-1.1.0.0

Like runLazyOutputMonoid, but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of runLazyOutputMonoid if the monoid is a list, such as String.

Warning: This inherits the nasty space leak issue of WriterT! Don't use this if you don't have to.

Since: polysemy-1.3.0.0

Like runOutputMonoid, but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of runOutputMonoid if the monoid is a list, such as String.

Since: polysemy-1.1.0.0

Run an Output effect by transforming it into a monoid, and accumulate it lazily.

Warning: This inherits the nasty space leak issue of WriterT! Don't use this if you don't have to.

Since: polysemy-1.3.0.0

Run an Output effect by transforming it into a monoid.

Since: polysemy-1.0.0.0

Run an Output effect by transforming it into a list of its values, lazily.

Warning: This inherits the nasty space leak issue of WriterT! Don't use this if you don't have to.

Since: polysemy-1.3.0.0

Run an Output effect by transforming it into a list of its values.

Since: polysemy-1.0.0.0

An effect capable of sending messages. Useful for streaming output and for logging.

Transform an Input effect into a Reader effect.

Since: polysemy-1.0.0.0

Run a Reader effect with a constant value.

An effect corresponding to ReaderT.

A more flexible --- though less safe --- version of resourceToIOFinal

This function is capable of running Resource effects anywhere within an effect stack, without relying on an explicit function to lower it into IO. Notably, this means that State effects will be consistent in the presence of Resource.

ResourceToIO' is safe whenever you're concerned about exceptions thrown by effects _already handled_ in your effect stack, or in IO code run directly inside of bracket. It is not safe against exceptions thrown explicitly at the main thread. If this is not safe enough for your use-case, use resourceToIOFinal instead.

This function creates a thread, and so should be compiled with -threaded.

Since: polysemy-1.0.0.0

Run a Resource effect purely.

Since: polysemy-1.0.0.0

Run a Resource effect in terms of bracket.

Since: polysemy-1.0.0.0

Run a Resource effect in terms of bracket through final IO

Beware: Effects that aren't interpreted in terms of IO will have local state semantics in regards to Resource effects interpreted this way. See Final.

Notably, unlike resourceToIO, this is not consistent with State unless runStateInIORef is used. State that seems like it should be threaded globally throughout brackets will not be.

Use resourceToIO instead if you need to run pure, stateful interpreters after the interpreter for Resource. (Pure interpreters are interpreters that aren't expressed in terms of another effect or monad; for example, runState.)

Since: polysemy-1.2.0.0

Like bracketOnError, but for the simple case of one computation to run afterward.

Since: polysemy-0.4.0.0

Like bracket, but for the simple case of one computation to run afterward.

Since: polysemy-0.4.0.0

A variant of bracket where the return value from the first computation is not required.

cf. bracket and bracket_

Since: polysemy-1.5.0.0

An effect capable of providing bracket semantics. Interpreters for this will successfully run the deallocation action even in the presence of other short-circuiting effects.

Hoist a State effect into a StateT monad transformer. This can be useful when writing interpreters that need to interop with MTL.

Since: polysemy-0.1.3.0

Run an State effect in terms of operations in ST.

Internally, this simply creates a new STRef, passes it to runStateSTRef, and then returns the result and the final value of the STRef.

Beware: As this uses an STRef internally, all other effects will have local state semantics in regards to State effects interpreted this way. For example, throw and catch will never revert puts, even if runError is used after stateToST.

When not using the plugin, one must introduce the existential st type to stateToST, so that the resulting type after runM can be resolved into forall st. ST st (s, a) for use with runST. Doing so requires -XScopedTypeVariables.

stResult :: forall s a. (s, a)
stResult = runST ( (runM $ stateToST @_ @st undefined $ pure undefined) :: forall st. ST st (s, a) )

Since: polysemy-1.3.0.0

Run a State effect by transforming it into operations over an STRef.

Since: polysemy-1.3.0.0

Run an State effect in terms of operations in IO.

Internally, this simply creates a new IORef, passes it to runStateIORef, and then returns the result and the final value of the IORef.

Note: This is not safe in a concurrent setting, as modify isn't atomic. If you need operations over the state to be atomic, use atomicStateToIO instead.

Beware: As this uses an IORef internally, all other effects will have local state semantics in regards to State effects interpreted this way. For example, throw and catch will never revert puts, even if runError is used after stateToIO.

Since: polysemy-1.2.0.0

Run a State effect by transforming it into operations over an IORef.

Note: This is not safe in a concurrent setting, as modify isn't atomic. If you need operations over the state to be atomic, use runAtomicStateIORef or runAtomicStateTVar instead.

Since: polysemy-1.0.0.0

Run a State effect with local state, lazily.

Since: polysemy-1.2.3.1

Run a State effect with local state, lazily.

Since: polysemy-1.0.0.0

Run a State effect with local state, lazily.

Run a State effect with local state.

Since: polysemy-1.2.3.1

Run a State effect with local state.

Since: polysemy-1.0.0.0

Run a State effect with local state.

A variant of modify in which the computation is strict in the new state.

An effect for providing statefulness. Note that unlike mtl's StateT, there is no restriction that the State effect corresponds necessarily to local state. It could could just as well be interrpeted in terms of HTTP requests or database access.

Interpreters which require statefulness can reinterpret themselves in terms of State, and subsequently call runState.

Transform a Tagged k1 e effect into a Tagged k2 e effect

Run a Tagged k e effect through reinterpreting it to e

A reinterpreting version of tag.

Tag uses of an effect, effectively gaining access to the tagged effect locally.

This may be used to create tagged- variants of regular actions.

For example:

taggedLocal :: forall k i r a
             . Member (Tagged k (Reader i)) r
            => (i -> i)
            -> Sem r a
            -> Sem r a
taggedLocal f m =
  tag k (Reader i) $ local @i f (raise m)

An effect for annotating effects and disambiguating identical effects.

Like writerToIOFinal. but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of writerToIOFinal if the monoid is a list, such as String.

Beware: Effects that aren't interpreted in terms of IO will have local state semantics in regards to Writer effects interpreted this way. See Final.

Since: polysemy-1.2.0.0

Run a Writer effect by transforming it into atomic operations through final IO.

Internally, this simply creates a new TVar, passes it to runWriterTVar, and then returns the result and the final value of the TVar.

Beware: Effects that aren't interpreted in terms of IO will have local state semantics in regards to Writer effects interpreted this way. See Final.

Since: polysemy-1.2.0.0

Transform a Writer effect into atomic operations over a TVar through final IO.

Since: polysemy-1.2.0.0

Like runLazyWriter, but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of runLazyWriter if the monoid is a list, such as String.

Warning: This inherits the nasty space leak issue of WriterT! Don't use this if you don't have to.

Since: polysemy-1.3.0.0

Like runWriter, but right-associates uses of <>.

This asymptotically improves performance if the time complexity of <> for the Monoid depends only on the size of the first argument.

You should always use this instead of runWriter if the monoid is a list, such as String.

Since: polysemy-1.1.0.0

Run a Writer effect in the style of WriterT lazily.

Warning: This inherits the nasty space leak issue of WriterT! Don't use this if you don't have to.

Since: polysemy-1.3.0.0

Run a Writer effect in the style of WriterT (but without the nasty space leak!)

Transform an Output effect into a Writer effect.

Since: polysemy-1.0.0.0

Since: polysemy-0.7.0.0

Transform a Writer o effect into a Writer (Endo o) effect, right-associating all uses of <> for o.

This can be used together with raiseUnder in order to create -AssocR variants out of regular Writer interpreters.

Since: polysemy-1.2.0.0

An effect capable of emitting and intercepting messages.

Convenience type alias for concatenating two effect rows.

Run an IO via Embed and catch all exceptions, returning Either.

Run an IO via Embed and catch all exceptions, returning Maybe.

Run an IO via Embed and catch and ignore all exceptions.

Convenience alias for pureT ().

Embed an effect into a Sem. This is used primarily via makeSem to implement smart constructors.