Turn a "state-modifying Pipe" into a Pipe that runs over StateT, so you can chain it with other StateT pipes.

Note that this will overwrite whatever state exists with the s that it gets when it terminates. If any other pipe in this chain modifies or uses state, all modifications will be overwritten when the (a, s)-producing pipe terminates.

Since: 0.2.1.0

Turn a Pipe that runs over StateT into a "state-modifying Pipe", that returns the final state when it terminates.

The main usage of this is to "isolate" the state from other pipes in the same chain. For example, of p, q, and r are all pipes under StateT, then:

    p
 .| q
 .| r

will all share underlying state, and each can modify the state that they all three share. We essentially have global state.

However, if you use runStateP, you can all have them use different encapsulated states.

    void (runStateP s0 p)
 .| void (runStateP s1 q)
 .| runStateP s2 r

In this case, each of those three chained pipes will use their own internal states, without sharing.

This is also useful if you want to chain a pipe over StateT with pipes that don't use state at all: for example if a and b are "non-stateful" pipes (not over StateT), you can do:

    a
 .| void (runStateP s1 q)
 .| b

And a and b will be none the wiser to the fact that q uses StateT internally.

Note to avoid the usage of void, evalStateP might be more useful.

Since: 0.2.1.0

Takes a Pipe over StateT and "hides" the state from the outside world. Give an initial state --- the pipe behaves the same way, but to the external user it is abstracted away. See runStateP for more information.

This can be cleaner than runStateP because if a is (), you don't have to sprinkle in void everywhere. However, it's only really useful if you don't need to get the final state upon termination.

Since: 0.2.1.0

Like runStateP, but ignoring the final result. It returns the final state after the pipe succesfuly terminates.

Since: 0.2.1.0

stateP, but for Control.Monad.Trans.State.Strict.

Since: 0.2.1.0

runStateP, but for Control.Monad.Trans.State.Strict.

Since: 0.2.1.0

evalStateP, but for Control.Monad.Trans.State.Strict.

Since: 0.2.1.0

execStateP, but for Control.Monad.Trans.State.Strict.

Since: 0.2.1.0

Turn a "failable-result" Pipe into a pipe over ExceptT.

Note that a throwE failure will only ever happen when the input pipe "succesfully" terminates with Left. It would never happen before the pipe terminates, since you don't get the Either e a until the pipe succesfully terminates.

Since: 0.2.1.0

Turn a Pipe that runs over ExceptT into an "early-terminating Pipe" that "succesfully" returns Left or Right.

The main usage of this is to "isolate" the short-circuiting failure of ExceptT to only happen within one component of a chain. For example, of p, q, and r are all pipes under ExceptT, then:

    p
 .| q
 .| r

will short-circuit fail if any of p, q, or r fail. We have global failure only.

However, if you use runExceptP, we isolate the short-circuiting failure to only a single type.

    void (runExceptP p)
 .| void (runExceptP q)
 .| runExceptP r

In this case, if (for example) q fails, it won't cause the whole thing to fail: it will just be the same as if q succesfully terminates normally.

This is also useful if you want to chain a pipe over ExceptT with pipes that don't have ExceptT at all: for example if a and b are "non-erroring" pipes (not over ExceptT), you can do:

    a
 .| void (runExceptP q)
 .| b

And a and b will be none the wiser to the fact that q uses ExceptT internally.

Note to avoid the usage of void, runExceptP_ might be more useful.

Since: 0.2.1.0

A handy version of runExceptP that discards its output, so it can be easier to chain using .|. It's useful if you are using runExceptP to "isolate" failures from the rest of a chain.

Since: 0.2.1.0

Turn a "parameterized Pipe" into a Pipe that runs over ReaderT, so you can chain it with other ReaderT pipes.

Essentially, instead of directly providing the r in an r -> Pipe i o u m a, the r instead comes from the globally shared environment.

Since: 0.2.1.0

Turn a pipe over ReaderT into a directly parameterized pipe. Instead of getting the parameter from the globally shared ReaderT environment, give it directly instead.

It can be useful to "ignore" a globally shared environment and just give the r directly and immediately.

Since: 0.2.1.0

Turn a pipe returning an (a, w) tuple upon termination into a pipe returning a, logging the w in an underlying WriterT context.

This can be useful for composing your pipe with other WriterT pipes, aggregating all to a common global log.

However, be aware that this only ever tells when the pipe succesfuly terminates. It doesn't do "streaming logging" -- it only makes one log payload at the point of succesful termination. To do streaming logging (logging things as you get them), you should probably just directly use WriterT instead, with repeatM or iterM or something similar.

Since: 0.2.1.0

Turn a Pipe that runs over WriterT into a Pipe that returns the final log when it terminates.

The main usage of this is to "isolate" the log from other pipes in the same chain. For example, of p, q, and r are all pipes under WriterT, then:

    p
 .| q
 .| r

will all share underlying log, and all logging from any of them will accumulate together in an interleaved way. It is essentially a global log.

However, if you use runWriterP, you can all have them use different encapsulated logs.

    void (runWriterP p)
 .| void (runWriterP q)
 .| runWriterP r

In this case, each of those three chained pipes will use their own internal logs, without sharing.

This is also useful if you want to chain a pipe over WriterT with pipes that don't use state at all: for example if a and b are "non-logging" pipes (not over WriterT), you can do:

    a
 .| void (runWriterP q)
 .| b

And a and b will be none the wiser to the fact that q uses WriterT internally.

Since: 0.2.1.0

runWriterP, but only returning the final log after succesful termination.

Since: 0.2.1.0

writerP, but for Control.Monad.Trans.Writer.Strict.

Since: 0.2.1.0

runWriterP, but for Control.Monad.Trans.Writer.Strict.

Since: 0.2.1.0

execWriterP, but for Control.Monad.Trans.Writer.Strict.

Since: 0.2.1.0

Turn a parameterized, state-transforming, log-producing Pipe into a Pipe over RWST, which can be useful for chaining it with other RWST pipes.

See stateP and writerP for more details on caveats, including:

• Logging only happens when the (a,s,w)-returning pipe terminates. There is no "streaming logging" --- the resulting w is logged all at once.
• When the (a,s,w)-returning pipe terminates, whatever state in the RWST is overwritten with the s returned. If other pipes in the chain modify the s, their modifications will be overwritten.

Since: 0.2.1.0

Turn a Pipe that runs over RWST into a state-modifying, environment-using, log-accumulating Pipe. See runStateP, runWriterP, and runReaderP for the uses and semantics.

Since: 0.2.1.0

runRWSP, but ignoring the final state.

Since: 0.2.1.0

runRWSP, but ignoring the result value.

Since: 0.2.1.0

rwsP, but for Control.Monad.Trans.RWS.Strict.

Since: 0.2.1.0

runRWSPS, but for Control.Monad.Trans.RWS.Strict.

Since: 0.2.1.0

evalRWSPS, but for Control.Monad.Trans.RWS.Strict.

Since: 0.2.1.0

execRWSPS, but for Control.Monad.Trans.RWS.Strict.

Since: 0.2.1.0

Like exceptP, but for CatchT. See exceptP for usage details and caveats. In general, can be useful for chaining with other CatchT pipes.

Note that a throwM failure will only ever happen when the input pipe "succesfully" terminates with Left. It would never happen before the pipe terminates, since you don't get the Either SomeException a until the pipe succesfully terminates.

Since: 0.2.1.0

Like runExceptP, but for CatchT. See runExceptP for usage details. In general, can be useful for "isolating" a CatchT pipe from the rest of its chain.

Since: 0.2.1.0