IO b -> b

unsafeLocalState :: IO a -> a
base Foreign.Marshal
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.
unsafePerformIO :: IO a -> a
base System.IO.Unsafe, base Foreign
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!
inlinePerformIO :: IO a -> a
text Data.Text.Unsafe
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. On Hugs this is just unsafePerformIO.
unsafeDupablePerformIO :: IO a -> a
text Data.Text.Unsafe
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.
makeGettableStateVar :: IO a -> GettableStateVar a
OpenGL Graphics.Rendering.OpenGL.GL.StateVar
Construct a GettableStateVar from an IO action.
block :: IO a -> IO a
base Control.Exception.Base, base Control.Exception, base Control.OldException
Note: this function is deprecated, please use mask instead. Applying block to a computation will execute that computation with asynchronous exceptions blocked. That is, any thread which attempts to raise an exception in the current thread with Control.Exception.throwTo will be blocked until asynchronous exceptions are unblocked again. There's no need to worry about re-enabling asynchronous exceptions; that is done automatically on exiting the scope of block. Threads created by Control.Concurrent.forkIO inherit the blocked state from the parent; that is, to start a thread in blocked mode, use block $ forkIO .... This is particularly useful if you need to establish an exception handler in the forked thread before any asynchronous exceptions are received.
mask_ :: IO a -> IO a
base Control.Exception.Base, base Control.Exception
Like mask, but does not pass a restore action to the argument.
runInBoundThread :: IO a -> IO a
base Control.Concurrent
Run the IO computation passed as the first argument. If the calling thread is not bound, a bound thread is created temporarily. runInBoundThread doesn't finish until the IO computation finishes. You can wrap a series of foreign function calls that rely on thread-local state with runInBoundThread so that you can use them without knowing whether the current thread is bound.
runInUnboundThread :: IO a -> IO a
base Control.Concurrent
Run the IO computation passed as the first argument. If the calling thread is bound, an unbound thread is created temporarily using forkIO. runInBoundThread doesn't finish until the IO computation finishes. Use this function only in the rare case that you have actually observed a performance loss due to the use of bound threads. A program that doesn't need it's main thread to be bound and makes heavy use of concurrency (e.g. a web server), might want to wrap it's main action in runInUnboundThread. Note that exceptions which are thrown to the current thread are thrown in turn to the thread that is executing the given computation. This ensures there's always a way of killing the forked thread.
unblock :: IO a -> IO a
base Control.Exception.Base, base Control.Exception, base Control.OldException
Note: this function is deprecated, please use mask instead. To re-enable asynchronous exceptions inside the scope of block, unblock can be used. It scopes in exactly the same way, so on exit from unblock asynchronous exception delivery will be disabled again.
uninterruptibleMask_ :: IO a -> IO a
base Control.Exception.Base, base Control.Exception
Like uninterruptibleMask, but does not pass a restore action to the argument.
unsafeInterleaveIO :: IO a -> IO a
base System.IO.Unsafe
unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. This is used to implement lazy file reading, see System.IO.hGetContents.
discardingRasterizer :: IO a -> IO a
OpenGL Graphics.Rendering.OpenGL.GL.PerFragment
preservingMatrix :: IO a -> IO a
OpenGL Graphics.Rendering.OpenGL.GL.CoordTrans
Push the current matrix stack down by one, duplicating the current matrix, excute the given action, and pop the current matrix stack, replacing the current matrix with the one below it on the stack (i.e. restoring it to its previous state). The returned value is that of the given action. Note that a round-trip to the server is probably required. For a more efficient version, see unsafePreservingMatrix.
unsafePreservingMatrix :: IO a -> IO a
OpenGL Graphics.Rendering.OpenGL.GL.CoordTrans
A more efficient, but potentially dangerous version of preservingMatrix: The given action is not allowed to throw an exception or change the current matrix mode permanently.
withSocketsDo :: IO a -> IO a
network Network.Socket.Internal, network Network.Socket, network Network
On Windows operating systems, the networking subsystem has to be initialised using withSocketsDo before any networking operations can be used. eg. > main = withSocketsDo $ do {...} Although this is only strictly necessary on Windows platforms, it is harmless on other platforms, so for portability it is good practice to use it all the time.
runIO :: IO a -> Q a
template-haskell Language.Haskell.TH.Syntax, template-haskell Language.Haskell.TH
The runIO function lets you run an I/O computation in the Q monad. Take care: you are guaranteed the ordering of calls to runIO within a single Q computation, but not about the order in which splices are run. Note: for various murky reasons, stdout and stderr handles are not necesarily flushed when the compiler finishes running, so you should flush them yourself.
unsafeIOToSTM :: IO a -> STM a
base GHC.Conc.Sync, base GHC.Conc
Unsafely performs IO in the STM monad. Beware: this is a highly dangerous thing to do. * The STM implementation will often run transactions multiple times, so you need to be prepared for this if your IO has any side effects. * The STM implementation will abort transactions that are known to be invalid and need to be restarted. This may happen in the middle of unsafeIOToSTM, so make sure you don't acquire any resources that need releasing (exception handlers are ignored when aborting the transaction). That includes doing any IO using Handles, for example. Getting this wrong will probably lead to random deadlocks. * The transaction may have seen an inconsistent view of memory when the IO runs. Invariants that you expect to be true throughout your program may not be true inside a transaction, due to the way transactions are implemented. Normally this wouldn't be visible to the programmer, but using unsafeIOToSTM can expose it.
qRunIO :: Quasi m => IO a -> m a
template-haskell Language.Haskell.TH.Syntax
liftIO :: MonadIO m => IO a -> m a
cgi Network.CGI, transformers Control.Monad.IO.Class

Show more results