IO package:base-compat

A value of type IO a is a computation which, when performed, does some I/O before returning a value of type a. There is really only one way to "perform" an I/O action: bind it to Main.main in your program. When your program is run, the I/O will be performed. It isn't possible to perform I/O from an arbitrary function, unless that function is itself in the IO monad and called at some point, directly or indirectly, from Main.main. IO is a monad, so IO actions can be combined using either the do-notation or the >> and >>= operations from the Monad class.

The Haskell 2010 type for exceptions in the IO monad. Any I/O operation may raise an IOException instead of returning a result. For a more general type of exception, including also those that arise in pure code, see Exception. In Haskell 2010, this is an opaque type.

Raise an IOException in the IO monad.

Convert an IO action to an ST action. This relies on IO and ST having the same representation modulo the constraint on the state thread type parameter.

Convert an ST action to an IO action. This relies on IO and ST having the same representation modulo the constraint on the state thread type parameter. For an example demonstrating why this is unsafe, see https://mail.haskell.org/pipermail/haskell-cafe/2009-April/060719.html

Strict version of atomicModifyIORef. This forces both the value stored in the IORef and the value returned. The new value is installed in the IORef before the returned value is forced. So

atomicModifyIORef' ref (x -> (x+1, undefined))

will increment the IORef and then throw an exception in the calling thread. This function imposes a memory barrier, preventing reordering; see Data.IORef#memmodel for details.

Variant of writeIORef. The prefix "atomic" relates to a fact that it imposes a reordering barrier, similar to atomicModifyIORef. Such a write will not be reordered with other reads or writes even on CPUs with weak memory model.

Strict version of modifyIORef. This is not an atomic update, consider using atomicModifyIORef' when operating in a multithreaded environment.

The partition function takes a predicate p and a stream xs, and returns a pair of lists. The first list corresponds to the elements of xs for which p holds; the second corresponds to the elements of xs for which p does not hold.

'partition' p xs = ('filter' p xs, 'filter' (not . p) xs)

The permutations function returns the list of all permutations of the argument. Since: 4.20.0.0

permutations1 operates like permutations, but uses the knowledge that its input is non-empty to produce output where every element is non-empty.

permutations1 = fmap fromList . permutations . toList

Since: 4.20.0.0

Construct tag-less Version

Fractional numbers, supporting real division. The Haskell Report defines no laws for Fractional. However, (+) and (*) are customarily expected to define a division ring and have the following properties:

• recip gives the multiplicative inverse x * recip x = recip x * x = fromInteger 1
• Totality of toRational toRational is total
• Coherence with toRational if the type also implements Real, then fromRational is a left inverse for toRational, i.e. fromRational (toRational i) = i

Note that it isn't customarily expected that a type instance of Fractional implement a field. However, all instances in base do.

Arbitrary-precision rational numbers, represented as a ratio of two Integer values. A rational number may be constructed using the % operator.

Conversion from a Rational (that is Ratio Integer). A floating literal stands for an application of fromRational to a value of type Rational, so such literals have type (Fractional a) => a.

The function properFraction takes a real fractional number x and returns a pair (n,f) such that x = n+f, and:

• n is an integral number with the same sign as x; and
• f is a fraction with the same type and sign as x, and with absolute value less than 1.

The default definitions of the ceiling, floor, truncate and round functions are in terms of properFraction.

The readIO function is similar to read except that it signals parse failure to the IO monad instead of terminating the program.

the rational equivalent of its real argument with full precision

This version of unsafePerformIO is more efficient because it omits the check that the IO is only being performed by a single thread. Hence, when you use unsafeDupablePerformIO, there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. It may even happen that one of the duplicated IO actions is only run partially, and then interrupted in the middle without an exception being raised. Therefore, functions like bracket cannot be used safely within unsafeDupablePerformIO.

A slightly faster version of fixIO that may not be safe to use with multiple threads. The unsafety arises when used like this:

unsafeFixIO $ \r -> do
forkIO (print r)
return (...)

In this case, the child thread will receive a NonTermination exception instead of waiting for the value of r to be computed.