forever -package:essence-of-live-coding

Repeat an action indefinitely.

Examples

A common use of forever is to process input from network sockets, Handles, and channels (e.g. MVar and Chan). For example, here is how we might implement an echo server, using forever both to listen for client connections on a network socket and to echo client input on client connection handles:

echoServer :: Socket -> IO ()
echoServer socket = forever $ do
client <- accept socket
forkFinally (echo client) (\_ -> hClose client)
where
echo :: Handle -> IO ()
echo client = forever $
hGetLine client >>= hPutStrLn client

Note that "forever" isn't necessarily non-terminating. If the action is in a MonadPlus and short-circuits after some number of iterations. then forever actually returns mzero, effectively short-circuiting its caller.

Repeat an action indefinitely. Using ApplicativeDo: 'forever as' can be understood as the pseudo-do expression

do as
as
..

with as repeating.

Examples

A common use of forever is to process input from network sockets, Handles, and channels (e.g. MVar and Chan). For example, here is how we might implement an echo server, using forever both to listen for client connections on a network socket and to echo client input on client connection handles:

echoServer :: Socket -> IO ()
echoServer socket = forever $ do
client <- accept socket
forkFinally (echo client) (\_ -> hClose client)
where
echo :: Handle -> IO ()
echo client = forever $
hGetLine client >>= hPutStrLn client

forever act repeats the action infinitely.

A shorthand for looping a Chunk forever.

Like forever but sans space leak

Execute the stream until it throws an exception, then restart it. One might be tempted to define this function recursively with applyExcept, but this would result in a runtime error, trying to define an infinite state.

"for every"

Run a consuming conduit repeatedly, only stopping when there is no more data available from upstream.

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.

Wait for input forever, calling the given inner component for each piece of new input. This function is provided as a convenience for the common pattern of awaiting input, checking if it's Just and then looping. Since 0.5.0

Wait for input forever, calling the given inner Pipe for each piece of new input. Returns the upstream result type. Since 0.5.0

Handle all incoming requests from the given SocketServer.

Convenience function to completely set up a TCP SocketServer and handle all incoming requests. This function is literally this:

serveTCPforever options func =
do sockserv <- setupSocketServer options
serveForever sockserv func

The animation will restart once the end is reached

Open a connection to the Redis server, register to all channels in the PubSubController, and process messages and subscription change requests forever. The only way this will ever exit is if there is an exception from the network code or an unhandled exception in a MessageCallback or PMessageCallback. For example, if the network connection to Redis dies, pubSubForever will throw a ConnectionLost. When such an exception is thrown, you can recall pubSubForever with the same PubSubController which will open a new connection and resubscribe to all the channels which are tracked in the PubSubController. The general pattern is therefore during program startup create a PubSubController and fork a thread which calls pubSubForever in a loop (using an exponential backoff algorithm such as the retry package to not hammer the Redis server if it does die). For example,

myhandler :: ByteString -> IO ()
myhandler msg = putStrLn $ unpack $ decodeUtf8 msg

onInitialComplete :: IO ()
onInitialComplete = putStrLn "Redis acknowledged that mychannel is now subscribed"

main :: IO ()
main = do
conn <- connect defaultConnectInfo
pubSubCtrl <- newPubSubController [("mychannel", myhandler)] []
concurrently ( forever $
pubSubForever conn pubSubCtrl onInitialComplete
`catch` (\(e :: SomeException) -> do
putStrLn $ "Got error: " ++ show e
threadDelay $ 50*1000) -- TODO: use exponential backoff
) $ restOfYourProgram


{- elsewhere in your program, use pubSubCtrl to change subscriptions -}

At most one active pubSubForever can be running against a single PubSubController at any time. If two active calls to pubSubForever share a single PubSubController there will be deadlocks. If you do want to process messages using multiple connections to Redis, you can create more than one PubSubController. For example, create one PubSubController for each getNumCapabilities and then create a Haskell thread bound to each capability each calling pubSubForever in a loop. This will create one network connection per controller/capability and allow you to register separate channels and callbacks for each controller, spreading the load across the capabilities.

essentially infinite caching; in reality, probably one year