Your intended one-stop-shop for conduit functionality.
This re-exports functions from many commonly used modules.
When there is a conflict with standard functions, functions
in this module are disambiguated by adding a trailing C
(or for chunked functions, replacing a trailing E with CE).
This means that the Conduit module can be imported unqualified
without causing naming conflicts.
For more information on the naming scheme and intended usages of the
combinators, please see the Data.Conduit.Combinators documentation.
The simplest buffer allocation strategy: whenever a buffer is requested,
allocate a new one that is big enough for the next build step to execute.
NOTE that this allocation strategy may spill quite some memory upon direct
insertion of a bytestring by the builder. Thats no problem for garbage
collection, but it may lead to unreasonably high memory consumption in
special circumstances.
Run a consuming conduit repeatedly, only stopping when there is no more
data available from upstream.
In contrast to peekForever, this function will ignore empty
chunks of data. So for example, if a stream of data contains an
empty ByteString, it is still treated as empty, and the consuming
function is not called.
Cautious version of sinkFile. The idea here is to stream the
values to a temporary file in the same directory of the destination
file, and only on successfully writing the entire file, moves it
atomically to the destination path.
In the event of an exception occurring, the temporary file will be
deleted and no move will be made. If the application shuts down
without running exception handling (such as machine failure or a
SIGKILL), the temporary file will remain and the destination file
will be untouched.
Stream incoming builders, executing them directly on the buffer of the
given Handle. Note that this function does not automatically close the
Handle when processing completes.
Pass flush to flush the buffer.
An alternative to sinkHandle.
Instead of taking a pre-opened Handle, it takes an action that opens
a Handle (in write mode), so that it can open it only when needed
and close it as soon as possible.
Stream data into a temporary file in the given directory with the
given filename pattern, and return the temporary filename. The
temporary file will be automatically deleted when exiting the
active ResourceT block, if it still exists.
Sink incoming values into a vector, up until size maxSize. Subsequent
values will be left in the stream. If there are less than maxSize values
present, returns a Vector of smaller size.
Note that using this function is more memory efficient than sinkList and
then converting to a Vector, as it avoids intermediate list constructors.
Stream the contents of the given directory, without traversing deeply.
This function will return all of the contents of the directory, whether
they be files, directories, etc.
Note that the generated filepaths will be the complete path, not just the
filename. In other words, if you have a directory foo containing files
bar and baz, and you use sourceDirectory on foo, the results will be
foo/bar and foo/baz.
Deeply stream the contents of the given directory.
This works the same as sourceDirectory, but will not return directories at
all. This function also takes an extra parameter to indicate whether
symlinks will be followed.
Stream the contents of a Handle as binary data. Note that this
function will not automatically close the Handle when processing
completes, since it did not acquire the Handle in the first place.
Same as sourceHandle, but instead of allocating a new buffer for each
incoming chunk of data, reuses the same buffer. Therefore, the ByteStrings
yielded by this function are not referentially transparent between two
different yields.
This function will be slightly more efficient than sourceHandle by
avoiding allocations and reducing garbage collections, but should only be
used if you can guarantee that you do not reuse a ByteString (or any slice
thereof) between two calls to await.
An alternative to sourceHandle.
Instead of taking a pre-opened Handle, it takes an action that opens
a Handle (in read mode), so that it can open it only when needed
and close it as soon as possible.
Incrementally execute builders on the given buffer and pass on the filled
chunks as bytestrings. Note that, if the given buffer is too small for the
execution of a build step, a larger one will be allocated.
WARNING: This conduit yields bytestrings that are NOT
referentially transparent. Their content will be overwritten as soon
as control is returned from the inner sink!
Apply the function to each value in the stream, resulting in a foldable
value (e.g., a list). Then yield each of the individual values in that
foldable value separately.
Apply the function to each element in the chunked stream, resulting in a
foldable value (e.g., a list). Then yield each of the individual values in
that foldable value separately.
Apply the monadic function to each value in the stream, resulting in a
foldable value (e.g., a list). Then yield each of the individual values in
that foldable value separately.
Generalizes concatMapM, mapMaybeM, and mapFoldableM.
Break up a stream of values into vectors of size n. The final vector may
be smaller than n if the total number of values is not a strict multiple of
n. No empty vectors will be yielded.
Convert a stream of arbitrarily-chunked textual data into a stream of data
where each chunk represents a single line. Note that, if you have
unknownuntrusted input, this function is unsafe/, since it would allow an
attacker to form lines of massive length and exhaust memory.
mapWhileC with a break condition dependent on a strict accumulator.
Equivalently, CL.mapAccum as long as the result is Right. Instead of
producing a leftover, the breaking input determines the resulting
accumulator via Left.
Note that, if downstream terminates early, not all values will be consumed.
If you want to force exactly the given number of values to be consumed,
see takeExactly.
Stream up to n number of elements downstream in a chunked stream.
Note that, if downstream terminates early, not all values will be consumed.
If you want to force exactly the given number of values to be consumed,
see takeExactlyE.
Consume precisely the given number of values and feed them downstream.
This function is in contrast to take, which will only consume up to the
given number of values, and will terminate early if downstream terminates
early. This function will discard any additional values in the stream if
they are unconsumed.
Note that this function takes a downstream ConduitT as a parameter, as
opposed to working with normal fusion. For more information, see
http://www.yesodweb.com/blog/2013/10/core-flaw-pipes-conduit, the section
titled "pipes and conduit: isolate".
Generally speaking, yielding values from inside a Conduit requires
some allocation for constructors. This can introduce an overhead,
similar to the overhead needed to represent a list of values instead of
a vector. This overhead is even more severe when talking about unboxed
values.
This combinator allows you to overcome this overhead, and efficiently
fill up vectors. It takes two parameters. The first is the size of each
mutable vector to be allocated. The second is a function. The function
takes an argument which will yield the next value into a mutable
vector.
A buffer allocation strategy (buf0, nextBuf) specifies the initial
buffer to use and how to compute a new buffer nextBuf minSize buf with at
least size minSize from a filled buffer buf. The double nesting of the
IO monad helps to ensure that the reference to the filled buffer buf is
lost as soon as possible, but the new buffer doesn't have to be allocated
too early.
Monads in which IO computations may be embedded.
Any monad built by applying a sequence of monad transformers to the
IO monad will be an instance of this class.
Instances should satisfy the following laws, which state that liftIO
is a transformer of monads:
Lift a computation from the IO monad.
This allows us to run IO computations in any monadic stack, so long as it supports these kinds of operations
(i.e. IO is the base monad for the stack).
Example
import Control.Monad.Trans.State -- from the "transformers" library
printState :: Show s => StateT s IO ()
printState = do
state <- get
liftIO $ print state
Had we omitted liftIO, we would have ended up with this error:
• Couldn't match type ‘IO’ with ‘StateT s IO’
Expected type: StateT s IO ()
Actual type: IO ()
The important part here is the mismatch between StateT s IO () and IO ().
Luckily, we know of a function that takes an IO a and returns an (m a): liftIO,
enabling us to run the program and see the expected results:
The class of monad transformers.
For any monad m, the result t m should also be a monad,
and lift should be a monad transformation from m to t m,
i.e. it should satisfy the following laws:
Since 0.6.0.0 and for GHC 8.6 and later, the requirement that t m
be a Monad is enforced by the implication constraint
forall m. Monad m => Monad (t m) enabled by the
QuantifiedConstraints extension.
Throw an exception. Note that this throws when this action is run in
the monad m, not when it is applied. It is a generalization of
Control.Exception's throwIO.
Should satisfy the law:
throwM e >> f = throwM e
Instances23MonadThrow, …
MonadThrowMaybeDefined in exceptions-0.10.12 · Control.Monad.Catch
MonadThrowSTMDefined in exceptions-0.10.12 · Control.Monad.Catch
MonadThrowQDefined in exceptions-0.10.12 · Control.Monad.Catch
MonadThrowIODefined in exceptions-0.10.12 · Control.Monad.Catch
MonadThrow []Defined in exceptions-0.10.12 · Control.Monad.Catch
MonadThrow (STs)Defined in exceptions-0.10.12 · Control.Monad.Catch
While MonadIO allows an IO action to be lifted into another
monad, this class captures the opposite concept: allowing you to
capture the monadic context. Note that, in order to meet the laws
given below, the intuition is that a monad must have no monadic
state, but may have monadic context. This essentially limits
MonadUnliftIO to ReaderT and IdentityT transformers on top of
IO.
Laws. For any function run provided by withRunInIO, it must meet the
monad transformer laws as reformulated for MonadUnliftIO:
run . return = return
run (m >>= f) = run m >>= run . f
Instances of MonadUnliftIO must also satisfy the following laws:
Identity law
withRunInIO (\run -> run m) = m
Inverse law
withRunInIO (\_ -> m) = liftIO m
As an example of an invalid instance, a naive implementation of
MonadUnliftIO (StateT s m) might be
Convenience function for capturing the monadic context and running an IO
action with a runner function. The runner function is used to run a monadic
action m in IO.
Instances4MonadUnliftIO
MonadUnliftIOIODefined in unliftio-core-0.2.1.0 · Control.Monad.IO.Unlift
A Monad which allows for safe resource allocation. In theory, any monad
transformer stack which includes a ResourceT can be an instance of
MonadResource.
Note: runResourceT has a requirement for a MonadUnliftIO m monad,
which allows control operations to be lifted. A MonadResource does not
have this requirement. This means that transformers such as ContT can be
an instance of MonadResource. However, the ContT wrapper will need to be
unwrapped before calling runResourceT.
The Resource transformer. This transformer keeps track of all registered
actions, and calls them upon exit (via runResourceT). Actions may be
registered via register, or resources may be allocated atomically via
allocate. allocate corresponds closely to bracket.
Releasing may be performed before exit via the release function. This is a
highly recommended optimization, as it will ensure that scarce resources are
freed early. Note that calling release will deregister the action, so that
a release action will only ever be called once.
Unwrap a ResourceT transformer, and call all registered release actions.
Note that there is some reference counting involved due to resourceForkIO.
If multiple threads are sharing the same collection of resources, only the
last call to runResourceT will deallocate the resources.
NOTE Since version 1.2.0, this function will throw a
ResourceCleanupException if any of the cleanup functions throw an
exception.
Same as mkAcquire, but the cleanup function will be informed of how
cleanup was initiated. This allows you to distinguish, for example, between
normal and exceptional exits.
To acquire and free the resource in an arbitrary monad with MonadUnliftIO,
do the following:
A method for acquiring a scarce resource, providing the means of freeing
it when no longer needed. This data type provides
Functor/Applicative/Monad instances for composing different resources
together. You can allocate these resources using either the bracket
pattern (via with) or using ResourceT (via allocateAcquire).
This concept was originally introduced by Gabriel Gonzalez and described at:
http://www.haskellforall.com/2013/06/the-resource-applicative.html. The
implementation in this package is slightly different, due to taking a
different approach to async exception safety.
Instances4Monad, Functor, Applicative, MonadIO
MonadAcquireDefined in resourcet-1.3.0 · Data.Acquire.Internal
FunctorAcquireDefined in resourcet-1.3.0 · Data.Acquire.Internal