The Reader+IO monad. This is different from a ReaderT because:

• It's not a transformer, it hardcodes IO for simpler usage and error messages.
• Instances of typeclasses like MonadLogger are implemented using classes defined on the environment, instead of using an underlying monad.

Using the environment run in IO the action that requires that environment.

Since: 0.0.1.0

Abstract RIO to an arbitrary MonadReader instance, which can handle IO.

Since: 0.0.1.0

Given a LogOptions value, run the given function with the specified LogFunc. A common way to use this function is:

let isVerbose = False -- get from the command line instead
logOptions' <- logOptionsHandle stderr isVerbose
let logOptions = setLogUseTime True logOptions'
withLogFunc logOptions $ \lf -> do
  let app = App -- application specific environment
        { appLogFunc = lf
        , appOtherStuff = ...
        }
  runRIO app $ do
    logInfo "Starting app"
    myApp

Since: 0.0.0.0

Given a LogOptions value, returns both a new LogFunc and a sub-routine that disposes it.

Intended for use if you want to deal with the teardown of LogFunc yourself, otherwise prefer the withLogFunc function instead.

Since: 0.1.3.0

A logging function, wrapped in a newtype for better error messages.

An implementation may choose any behavior of this value it wishes, including printing to standard output or no action at all.

Since: 0.0.0.0

Environment values with a logging function.

Since: 0.0.0.0

Create a LogOptions value from the given Handle and whether to perform verbose logging or not. Individiual settings can be overridden using appropriate set functions.

When Verbose Flag is True, the following happens:

• setLogVerboseFormat is called with True
• setLogUseColor is called with True (except on Windows)
• setLogUseLoc is called with True
• setLogUseTime is called with True
• setLogMinLevel is called with Debug log level

Since: 0.0.0.0

Configuration for how to create a LogFunc. Intended to be used with the withLogFunc function.

Since: 0.0.0.0

Set the minimum log level. Messages below this level will not be printed.

Default: in verbose mode, LevelDebug. Otherwise, LevelInfo.

Since: 0.0.0.0

Refer to setLogMinLevel. This modifier allows to alter the verbose format value dynamically at runtime.

Default: in verbose mode, LevelDebug. Otherwise, LevelInfo.

Since: 0.1.3.0

Use the verbose format for printing log messages.

Default: follows the value of the verbose flag.

Since: 0.0.0.0

Refer to setLogVerboseFormat. This modifier allows to alter the verbose format value dynamically at runtime.

Default: follows the value of the verbose flag.

Since: 0.1.3.0

Do we treat output as a terminal. If True, we will enabled sticky logging functionality.

Default: checks if the Handle provided to logOptionsHandle is a terminal with hIsTerminalDevice.

Since: 0.0.0.0

Include the time when printing log messages.

Default: True in debug mode, False otherwise.

Since: 0.0.0.0

Use ANSI color codes in the log output.

Default: True if in verbose mode and the Handle is a terminal device.

Since: 0.0.0.0

Use code location in the log output.

Default: True if in verbose mode, False otherwise.

Since: 0.1.2.0

Set format method for messages

Default: id

Since: 0.1.13.0

Log a debug level message with no source.

Since: 0.0.0.0

Log an info level message with no source.

Since: 0.0.0.0

Log a warn level message with no source.

Since: 0.0.0.0

Log an error level message with no source.

Since: 0.0.0.0

Log a message with the specified textual level and no source.

Since: 0.0.0.0

Write a "sticky" line to the terminal. Any subsequent lines will overwrite this one, and that same line will be repeated below again. In other words, the line sticks at the bottom of the output forever. Running this function again will replace the sticky line with a new sticky line. When you want to get rid of the sticky line, run logStickyDone.

Note that not all LogFunc implementations will support sticky messages as described. However, the withLogFunc implementation provided by this module does.

Since: 0.0.0.0

This will print out the given message with a newline and disable any further stickiness of the line until a new call to logSticky happens.

Since: 0.0.0.0

Log a debug level message with the given source.

Since: 0.0.0.0

Log an info level message with the given source.

Since: 0.0.0.0

Log a warn level message with the given source.

Since: 0.0.0.0

Log an error level message with the given source.

Since: 0.0.0.0

Log a message with the specified textual level and the given source.

Since: 0.0.0.0

Generic, basic function for creating other logging functions.

Since: 0.0.0.0

Create a LogFunc from the given function.

Since: 0.0.0.0

Create a LogOptions value which will store its data in memory. This is primarily intended for testing purposes. This will return both a LogOptions value and an IORef containing the resulting Builder value.

This will default to non-verbose settings and assume there is a terminal attached. These assumptions can be overridden using the appropriate set functions.

Since: 0.0.0.0

The log level of a message.

Since: 0.0.0.0

Where in the application a log message came from. Used for display purposes only.

Since: 0.0.0.0

CallStacks are a lightweight method of obtaining a partial call-stack at any point in the program.

A function can request its call-site with the HasCallStack constraint. For example, we can define

putStrLnWithCallStack :: HasCallStack => String -> IO ()

as a variant of putStrLn that will get its call-site and print it, along with the string given as argument. We can access the call-stack inside putStrLnWithCallStack with callStack.

putStrLnWithCallStack :: HasCallStack => String -> IO ()
putStrLnWithCallStack msg = do
  putStrLn msg
  putStrLn (prettyCallStack callStack)

Thus, if we call putStrLnWithCallStack we will get a formatted call-stack alongside our string.

>>> putStrLnWithCallStack "hello"
hello
CallStack (from HasCallStack):
  putStrLnWithCallStack, called at <interactive>:2:1 in interactive:Ghci1

GHC solves HasCallStack constraints in three steps:

1. If there is a CallStack in scope -- i.e. the enclosing function has a HasCallStack constraint -- GHC will append the new call-site to the existing CallStack.
2. If there is no CallStack in scope -- e.g. in the GHCi session above -- and the enclosing definition does not have an explicit type signature, GHC will infer a HasCallStack constraint for the enclosing definition (subject to the monomorphism restriction).
3. If there is no CallStack in scope and the enclosing definition has an explicit type signature, GHC will solve the HasCallStack constraint for the singleton CallStack containing just the current call-site.

CallStacks do not interact with the RTS and do not require compilation with -prof. On the other hand, as they are built up explicitly via the HasCallStack constraints, they will generally not contain as much information as the simulated call-stacks maintained by the RTS.

A CallStack is a [(String, SrcLoc)]. The String is the name of function that was called, the SrcLoc is the call-site. The list is ordered with the most recently called function at the head.

NOTE: The intrepid user may notice that HasCallStack is just an alias for an implicit parameter ?callStack :: CallStack. This is an implementation detail and should not be considered part of the CallStack API, we may decide to change the implementation in the future.

Since: base-4.8.1.0

Convert a CallStack value into a Utf8Builder indicating the first source location.

TODO Consider showing the entire call stack instead.

Since: 0.0.0.0

Disable logging capabilities in a given sub-routine

Intended to skip logging in general purpose implementations, where secrets might be logged accidently.

Since: 0.1.5.0

Is the log func configured to use color output?

Intended for use by code which wants to optionally add additional color to its log messages.

Since: 0.1.0.0

Log a value generically.

Since: 0.1.13.0

A generic logger of some type msg.

Your GLocFunc can re-use the existing classical logging framework of RIO, and/or implement additional transforms, filters. Alternatively, you may log to a JSON source in a database, or anywhere else as needed. You can decide how to log levels or severities based on the constructors in your type. You will normally determine this in your main app entry point.

Since: 0.1.13.0

Make a GLogFunc via classic LogFunc. Use this if you'd like to log your generic data type via the classic RIO terminal logger.

Since: 0.1.13.0

Make a custom generic logger. With this you could, for example, write to a database or a log digestion service. For example:

mkGLogFunc (\stack msg -> send (Data.Aeson.encode (JsonLog stack msg)))

Since: 0.1.13.0

A vesion of contramapMaybeGLogFunc which supports filering.

Since: 0.1.13.0

A contramap. Use this to wrap sub-loggers via mapRIO.

If you are on base > 4.12.0, you can just use contramap.

Since: 0.1.13.0

An app is capable of generic logging if it implements this.

Since: 0.1.13.0

Level, if any, of your logs. If unknown, use LogOther. Use for your generic log data types that want to sit inside the classic log framework.

Since: 0.1.13.0

Source of a log. This can be whatever you want. Use for your generic log data types that want to sit inside the classic log framework.

Since: 0.1.13.0

A builder of binary data, with the invariant that the underlying data is supposed to be UTF-8 encoded.

Since: 0.1.0.0

A typeclass for values which can be converted to a Utf8Builder. The intention of this typeclass is to provide a human-friendly display of the data.

Since: 0.1.0.0

Use the Show instance for a value to convert it to a Utf8Builder.

Since: 0.1.0.0

Convert a Utf8Builder value into a strict Text.

Since: 0.1.0.0

Convert a Utf8Builder value into a lazy Text.

Since: 0.1.0.0

Convert a ByteString into a Utf8Builder.

NOTE This function performs no checks to ensure that the data is, in fact, UTF8 encoded. If you provide non-UTF8 data, later functions may fail.

Since: 0.1.0.0

Write the given Utf8Builder value to a file.

Since: 0.1.0.0

ASetter s t a b is something that turns a function modifying a value into a function modifying a structure. If you ignore Identity (as Identity a is the same thing as a), the type is:

type ASetter s t a b = (a -> b) -> s -> t

The reason Identity is used here is for ASetter to be composable with other types, such as Lens.

Technically, if you're writing a library, you shouldn't use this type for setters you are exporting from your library; the right type to use is Setter, but it is not provided by this package (because then it'd have to depend on distributive). It's completely alright, however, to export functions which take an ASetter as an argument.

This is a type alias for monomorphic setters which don't change the type of the container (or of the value inside). It's useful more often than the same type in lens, because we can't provide real setters and so it does the job of both ASetter' and Setter'.

Functions that operate on getters and folds – such as (^.), (^..), (^?) – use Getter r s a (with different values of r) to describe what kind of result they need. For instance, (^.) needs the getter to be able to return a single value, and so it accepts a getter of type Getting a s a. (^..) wants the getter to gather values together, so it uses Getting (Endo [a]) s a (it could've used Getting [a] s a instead, but it's faster with Endo). The choice of r depends on what you want to do with elements you're extracting from s.

Lens s t a b is the lowest common denominator of a setter and a getter, something that has the power of both; it has a Functor constraint, and since both Const and Identity are functors, it can be used whenever a getter or a setter is needed.

• a is the type of the value inside of structure
• b is the type of the replaced value
• s is the type of the whole structure
• t is the type of the structure after replacing a in it with b

This is a type alias for monomorphic lenses which don't change the type of the container (or of the value inside).

A SimpleGetter s a extracts a from s; so, it's the same thing as (s -> a), but you can use it in lens chains because its type looks like this:

type SimpleGetter s a =
  forall r. (a -> Const r a) -> s -> Const r s

Since Const r is a functor, SimpleGetter has the same shape as other lens types and can be composed with them. To get (s -> a) out of a SimpleGetter, choose r ~ a and feed Const :: a -> Const a a to the getter:

-- the actual signature is more permissive:
-- view :: Getting a s a -> s -> a
view :: SimpleGetter s a -> s -> a
view getter = getConst . getter Const

The actual Getter from lens is more general:

type Getter s a =
  forall f. (Contravariant f, Functor f) => (a -> f a) -> s -> f s

I'm not currently aware of any functions that take lens's Getter but won't accept SimpleGetter, but you should try to avoid exporting SimpleGetters anyway to minimise confusion. Alternatively, look at microlens-contra, which provides a fully lens-compatible Getter.

Lens users: you can convert a SimpleGetter to Getter by applying to . view to it.

lens creates a Lens from a getter and a setter. The resulting lens isn't the most effective one (because of having to traverse the structure twice when modifying), but it shouldn't matter much.

A (partial) lens for list indexing:

ix :: Int -> Lens' [a] a
ix i = lens (!! i)                                   -- getter
            (\s b -> take i s ++ b : drop (i+1) s)   -- setter

Usage:

>>> [1..9] ^. ix 3
4

>>> [1..9] & ix 3 %~ negate
[1,2,3,-4,5,6,7,8,9]

When getting, the setter is completely unused; when setting, the getter is unused. Both are used only when the value is being modified. For instance, here we define a lens for the 1st element of a list, but instead of a legitimate getter we use undefined. Then we use the resulting lens for setting and it works, which proves that the getter wasn't used:

>>> [1,2,3] & lens undefined (\s b -> b : tail s) .~ 10
[10,2,3]

over is a synonym for (%~).

Getting fmap in a roundabout way:

over mapped :: Functor f => (a -> b) -> f a -> f b
over mapped = fmap

Applying a function to both components of a pair:

over both :: (a -> b) -> (a, a) -> (b, b)
over both = \f t -> (f (fst t), f (snd t))

Using over _2 as a replacement for second:

>>> over _2 show (10,20)
(10,"20")

set is a synonym for (.~).

Setting the 1st component of a pair:

set _1 :: x -> (a, b) -> (x, b)
set _1 = \x t -> (x, snd t)

Using it to rewrite (<$):

set mapped :: Functor f => a -> f b -> f a
set mapped = (<$)

sets creates an ASetter from an ordinary function. (The only thing it does is wrapping and unwrapping Identity.)

to creates a getter from any function:

a ^. to f = f a

It's most useful in chains, because it lets you mix lenses and ordinary functions. Suppose you have a record which comes from some third-party library and doesn't have any lens accessors. You want to do something like this:

value ^. _1 . field . at 2

However, field isn't a getter, and you have to do this instead:

field (value ^. _1) ^. at 2

but now value is in the middle and it's hard to read the resulting code. A variant with to is prettier and more readable:

value ^. _1 . to field . at 2

(^.) applies a getter to a value; in other words, it gets a value out of a structure using a getter (which can be a lens, traversal, fold, etc.).

Getting 1st field of a tuple:

(^. _1) :: (a, b) -> a
(^. _1) = fst

When (^.) is used with a traversal, it combines all results using the Monoid instance for the resulting type. For instance, for lists it would be simple concatenation:

>>> ("str","ing") ^. each
"string"

The reason for this is that traversals use Applicative, and the Applicative instance for Const uses monoid concatenation to combine “effects” of Const.

A non-operator version of (^.) is called view, and it's a bit more general than (^.) (it works in MonadReader). If you need the general version, you can get it from microlens-mtl; otherwise there's view available in Lens.Micro.Extras.

A ThreadId is an abstract type representing a handle to a thread. ThreadId is an instance of Eq, Ord and Show, where the Ord instance implements an arbitrary total ordering over ThreadIds. The Show instance lets you convert an arbitrary-valued ThreadId to string form; showing a ThreadId value is occasionally useful when debugging or diagnosing the behaviour of a concurrent program.

Note: in GHC, if you have a ThreadId, you essentially have a pointer to the thread itself. This means the thread itself can't be garbage collected until you drop the ThreadId. This misfeature will hopefully be corrected at a later date.

Lifted version of myThreadId.

Since: unliftio-0.1.1.0

Lifted version of isCurrentThreadBound.

Since: unliftio-0.1.1.0

Lifted version of threadWaitRead.

Since: unliftio-0.1.1.0

Lifted version of threadWaitWrite.

Since: unliftio-0.1.1.0

Lifted version of threadDelay.

Since: unliftio-0.1.1.0

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

Lazily get the contents of a file. Unlike readFile, this ensures that if an exception is thrown, the file handle is closed immediately.

Lazily read a file in UTF8 encoding.

Since: 0.1.13

Same as readFile, but generalized to MonadIO

Same as writeFile, but generalized to MonadIO

Read a file in UTF8 encoding, throwing an exception on invalid character encoding.

This function will use OS-specific line ending handling.

Write a file in UTF8 encoding

This function will use OS-specific line ending handling.

Lifted version of "System.Exit.exitFailure".

@since 0.1.9.0.

Lifted version of "System.Exit.exitSuccess".

@since 0.1.9.0.

Lifted version of "System.Exit.exitWith".

@since 0.1.9.0.

Defines the exit codes that a program can return.

Environment values with writing capabilities to SomeRef

Since: 0.1.4.0

Environment values with stateful capabilities to SomeRef

Since: 0.1.4.0

Abstraction over how to read from and write to a mutable reference

Since: 0.1.4.0

Lift one RIO env to another.

Since: 0.1.13.0

Read from a SomeRef

Since: 0.1.4.0

Write to a SomeRef

Since: 0.1.4.0

Modify a SomeRef This function is subject to change due to the lack of atomic operations

Since: 0.1.4.0

create a new boxed SomeRef

Since: 0.1.4.0

create a new unboxed SomeRef

Since: 0.1.4.0

An unboxed reference. This works like an IORef, but the data is stored in a bytearray instead of a heap object, avoiding significant allocation overhead in some cases. For a concrete example, see this Stack Overflow question: https://stackoverflow.com/questions/27261813/why-is-my-little-stref-int-require-allocating-gigabytes.

The first parameter is the state token type, the same as would be used for the ST monad. If you're using an IO-based monad, you can use the convenience IOURef type synonym instead.

Since: 0.0.2.0

Helpful type synonym for using a URef from an IO-based stack.

Since: 0.0.2.0

Create a new URef

Since: 0.0.2.0

Read the value in a URef

Since: 0.0.2.0

Write a value into a URef. Note that this action is strict, and will force evalution of the value.

Since: 0.0.2.0

Modify a value in a URef. Note that this action is strict, and will force evaluation of the result value.

Since: 0.0.2.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0

Since: 0.1.0.0