:: IO String -> String

Sometimes an external entity is a pure function, except that it passes arguments and/or results via pointers. The function unsafeLocalState permits the packaging of such entities as pure functions. The only IO operations allowed in the IO action passed to unsafeLocalState are (a) local allocation (alloca, allocaBytes and derived operations such as withArray and withCString), and (b) pointer operations (Foreign.Storable and Foreign.Ptr) on the pointers to local storage, and (c) foreign functions whose only observable effect is to read and/or write the locally allocated memory. Passing an IO operation that does not obey these rules results in undefined behaviour. It is expected that this operation will be replaced in a future revision of Haskell.

This is the "back door" into the IO monad, allowing IO computation to be performed at any time. For this to be safe, the IO computation should be free of side effects and independent of its environment. If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Furthermore, when using unsafePerformIO to cause side-effects, you should take the following precautions to ensure the side effects are performed as many times as you expect them to be. Note that these precautions are necessary for GHC, but may not be sufficient, and other compilers may require different precautions:

• Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once.
• Use the compiler flag -fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like test in the example below).
• Make sure that the either you switch off let-floating (-fno-full-laziness), or that the call to unsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls to f. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.

It is less well known that unsafePerformIO is not type safe. For example:

test :: IORef [a]
test = unsafePerformIO $ newIORef []

main = do
writeIORef test [42]
bang <- readIORef test
print (bang :: [Char])

This program will core dump. This problem with polymorphic references is well known in the ML community, and does not arise with normal monadic use of references. There is no easy way to make it impossible once you use unsafePerformIO. Indeed, it is possible to write coerce :: a -> b with the help of unsafePerformIO. So be careful! WARNING: If you're looking for "a way to get a String from an 'IO String'", then unsafePerformIO is not the way to go. Learn about do-notation and the <- syntax element before you proceed.

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.

This "function" has a superficial similarity to unsafePerformIO but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet. Witness the trail of destruction:

• https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7
• https://github.com/haskell/bytestring/commit/210c656390ae617d9ee3b8bcff5c88dd17cef8da
• https://github.com/haskell/aeson/commit/720b857e2e0acf2edc4f5512f2b217a89449a89d
• https://ghc.haskell.org/trac/ghc/ticket/3486
• https://ghc.haskell.org/trac/ghc/ticket/3487
• https://ghc.haskell.org/trac/ghc/ticket/7270
• https://gitlab.haskell.org/ghc/ghc/-/issues/22204

Do not talk about "safe"! You do not know what is safe! Yield not to its blasphemous call! Flee traveller! Flee or you will be corrupted and devoured!

Just like unsafePerformIO, but we inline it. Big performance gains as it exposes lots of things to further inlining. Very unsafe. In particular, you should do no memory allocation inside an inlinePerformIO block.

Generally, do not use this function. It is the same as accursedUnutterablePerformIO from bytestring and is well behaved under narrow conditions. See the documentation of that function to get an idea of when this is sound. In most cases GHC.IO.Unsafe.unsafeDupablePerformIO should be preferred.

This is the "back door" into the IO monad, allowing IO computation to be performed at any time. For this to be safe, the IO computation should be free of side effects and independent of its environment. If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Furthermore, when using unsafePerformIO to cause side-effects, you should take the following precautions to ensure the side effects are performed as many times as you expect them to be. Note that these precautions are necessary for GHC, but may not be sufficient, and other compilers may require different precautions:

• Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once.
• Use the compiler flag -fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like test in the example below).
• Make sure that the either you switch off let-floating (-fno-full-laziness), or that the call to unsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls to f. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.

It is less well known that unsafePerformIO is not type safe. For example:

test :: IORef [a]
test = unsafePerformIO $ newIORef []

main = do
writeIORef test [42]
bang <- readIORef test
print (bang :: [Char])

This program will core dump. This problem with polymorphic references is well known in the ML community, and does not arise with normal monadic use of references. There is no easy way to make it impossible once you use unsafePerformIO. Indeed, it is possible to write coerce :: a -> b with the help of unsafePerformIO. So be careful!

Just like Unsafe.performIO, but we inline it. Big performance gains as it exposes lots of things to further inlining. Very unsafe. In particular, you should do no memory allocation inside an inlinePerformIO block. On Hugs this is just Unsafe.performIO.

This is the "back door" into the IO monad, allowing IO computation to be performed at any time. For this to be safe, the IO computation should be free of side effects and independent of its environment. If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Furthermore, when using unsafePerformIO to cause side-effects, you should take the following precautions to ensure the side effects are performed as many times as you expect them to be. Note that these precautions are necessary for GHC, but may not be sufficient, and other compilers may require different precautions:

• Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once.
• Use the compiler flag -fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like test in the example below).
• Make sure that the either you switch off let-floating (-fno-full-laziness), or that the call to unsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls to f. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.

It is less well known that unsafePerformIO is not type safe. For example:

test :: IORef [a]
test = unsafePerformIO $ newIORef []

main = do
writeIORef test [42]
bang <- readIORef test
print (bang :: [Char])

This program will core dump. This problem with polymorphic references is well known in the ML community, and does not arise with normal monadic use of references. There is no easy way to make it impossible once you use unsafePerformIO. Indeed, it is possible to write coerce :: a -> b with the help of unsafePerformIO. So be careful!

Pretty print something that may be converted to a list as a list. Each entry is on a separate line, which means that we don't do clever pretty printing, and so this works well for large strucutures.

The largest element of a non-empty structure. This function is equivalent to foldr1 max, and its behavior on structures with multiple largest elements depends on the relevant implementation of max. For the default implementation of max (max x y = if x <= y then y else x), structure order is used as a tie-breaker: if there are multiple largest elements, the rightmost of them is chosen (this is equivalent to maximumBy compare). This function is non-total and will raise a runtime exception if the structure happens to be empty. A structure that supports random access and maintains its elements in order should provide a specialised implementation to return the maximum in faster than linear time.

Examples

Basic usage:

>>> maximum [1..10]
10

>>> maximum []
*** Exception: Prelude.maximum: empty list

>>> maximum Nothing
*** Exception: maximum: empty structure

WARNING: This function is partial for possibly-empty structures like lists.

The least element of a non-empty structure. This function is equivalent to foldr1 min, and its behavior on structures with multiple largest elements depends on the relevant implementation of min. For the default implementation of min (min x y = if x <= y then x else y), structure order is used as a tie-breaker: if there are multiple least elements, the leftmost of them is chosen (this is equivalent to minimumBy compare). This function is non-total and will raise a runtime exception if the structure happens to be empty. A structure that supports random access and maintains its elements in order should provide a specialised implementation to return the minimum in faster than linear time.

Examples

Basic usage:

>>> minimum [1..10]
1

>>> minimum []
*** Exception: Prelude.minimum: empty list

>>> minimum Nothing
*** Exception: minimum: empty structure

WARNING: This function is partial for possibly-empty structures like lists.

The largest element of a non-empty structure. This function is non-total and will raise a runtime exception if the structure happens to be empty. A structure that supports random access and maintains its elements in order should provide a specialised implementation to return the maximum in faster than linear time.

Examples

Basic usage:

>>> maximum [1..10]
10

>>> maximum []
*** Exception: Prelude.maximum: empty list

>>> maximum Nothing
*** Exception: maximum: empty structure

WARNING: This function is partial for possibly-empty structures like lists.

The least element of a non-empty structure. This function is non-total and will raise a runtime exception if the structure happens to be empty. A structure that supports random access and maintains its elements in order should provide a specialised implementation to return the minimum in faster than linear time.

Examples

Basic usage:

>>> minimum [1..10]
1

>>> minimum []
*** Exception: Prelude.minimum: empty list

>>> minimum Nothing
*** Exception: minimum: empty structure

WARNING: This function is partial for possibly-empty structures like lists.

The largest element of a non-empty structure.

The least element of a non-empty structure.

The largest element of a non-empty structure.