Documentation

Construct an interpreter for a higher-order effect wrapped in a Scoped, given a resource allocation function and a parameterized handler for the plain effect.

This combinator is analogous to interpretH in that it allows the handler to use the Tactical environment and transforms the effect into other effects on the stack.

Variant of interpretScopedH that allows the resource acquisition function to use Tactical.

First-order variant of interpretScopedH.

Variant of interpretScoped in which the resource allocator is a plain action.

Higher-order interpreter for Scoped that allows the handler to use additional effects that are interpreted by the resource allocator.

Note: It is necessary to specify the list of local interpreters with a type application; GHC won't be able to figure them out from the type of withResource.

As an example for a higher order effect, consider a mutexed concurrent state effect, where an effectful function may lock write access to the state while making it still possible to read it:

data MState s :: Effect where
  MState :: (s -> m (s, a)) -> MState s m a
  MRead :: MState s m s

makeSem ''MState

We can now use an AtomicState to store the current value and lock write access with an MVar. Since the state callback is effectful, we need a higher order interpreter:

withResource ::
  Member (Embed IO) r =>
  s ->
  (MVar () -> Sem (AtomicState s : r) a) ->
  Sem r a
withResource initial use = do
  tv <- embed (newTVarIO initial)
  lock <- embed (newMVar ())
  runAtomicStateTVar tv $ use lock

interpretMState ::
  ∀ s r .
  Members [Resource, Embed IO] r =>
  InterpreterFor (Scoped s (MState s)) r
interpretMState =
  interpretScopedWithH @'[AtomicState s] withResource \ lock -> \case
    MState f ->
      bracket_ (embed (takeMVar lock)) (embed (tryPutMVar lock ())) do
        s0 <- atomicGet
        res <- runTSimple (f s0)
        Inspector ins <- getInspectorT
        for_ (ins res) \ (s, _) -> atomicPut s
        pure (snd <$> res)
    MRead ->
      liftT atomicGet

First-order variant of interpretScopedWithH.

Note: It is necessary to specify the list of local interpreters with a type application; GHC won't be able to figure them out from the type of withResource:

data SomeAction :: Effect where
  SomeAction :: SomeAction m ()

foo :: InterpreterFor (Scoped () SomeAction) r
foo =
  interpretScopedWith @[Reader Int, State Bool] localEffects \ () -> \case
    SomeAction -> put . (> 0) =<< ask @Int
  where
    localEffects () use = evalState False (runReader 5 (use ()))

Variant of interpretScopedWith in which no resource is used and the resource allocator is a plain interpreter. This is useful for scopes that only need local effects, but no resources in the handler.

See the Note on interpretScopedWithH.

Variant of interpretScoped that uses another interpreter instead of a handler.

This is mostly useful if you want to reuse an interpreter that you cannot easily rewrite (like from another library). If you have full control over the implementation, interpretScoped should be preferred.

Note: In previous versions of Polysemy, the wrapped interpreter was executed fully, including the initializing code surrounding its handler, for each action in the program. However, new and continuing discoveries regarding Scoped has allowed the improvement of having the interpreter be used only once per use of scoped, and have it cover the same scope of actions that withResource does.

This renders withResource practically redundant; for the moment, the API surrounding Scoped remains the same, but work is in progress to revamp the entire API of Scoped.

Variant of runScoped in which the resource allocator returns the resource rather tnen calling a continuation.

Combined higher-order interpreter for Scoped and Resumable. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope.

Combined interpreter for Scoped and Resumable. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope.

Combined interpreter for Scoped and Resumable. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope. In this variant, the resource allocator is a plain action.

Combined higher-order interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope.

Combined interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope.

Combined interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. This allows Stop to be sent from within the resource allocator so that the consumer receives it, terminating the entire scope. In this variant, no resource is used and the allocator is a plain interpreter.

Combined higher-order interpreter for Resumable and Scoped. In this variant, only the handler may send Stop, but this allows resumption to happen on each action inside of the scope.

Combined interpreter for Resumable and Scoped. In this variant, only the handler may send Stop, but this allows resumption to happen on each action inside of the scope.

Combined interpreter for Resumable and Scoped. In this variant: - Only the handler may send Stop, but this allows resumption to happen on each action inside of the scope. - The resource allocator is a plain action.

Combined higher-order interpreter for Resumable and Scoped that allows the handler to use additional effects that are interpreted by the resource allocator. In this variant, only the handler may send Stop, but this allows resumption to happen on each action inside of the scope.

Combined interpreter for Resumable and Scoped that allows the handler to use additional effects that are interpreted by the resource allocator. In this variant, only the handler may send Stop, but this allows resumption to happen on each action inside of the scope.

Combined interpreter for Resumable and Scoped that allows the handler to use additional effects that are interpreted by the resource allocator. In this variant: - Only the handler may send Stop, but this allows resumption to happen on each action inside of the scope. - No resource is used and the allocator is a plain interpreter.

Combined higher-order interpreter for Resumable and Scoped. In this variant, both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption.

Combined interpreter for Scoped and Resumable. In this variant, both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption.

Combined interpreter for Scoped and Resumable. In this variant: - Both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption. - The resource allocator is a plain action.

Combined higher-order interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. In this variant, both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption.

Combined interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. In this variant, both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption.

Combined interpreter for Scoped and Resumable that allows the handler to use additional effects that are interpreted by the resource allocator. - Both the handler and the scope may send different errors via Stop, encoding the concept that the resource allocation may fail to prevent the scope from being executed, and each individual scoped action may fail, continuing the scope execution on resumption. - The resource allocator is a plain action.