CODEWITHSUNDEEP
haskell
Michael Fox
Michael Fox

Reputation: 3642

Is there a lazy Session IO Monad?

You have a sequence of actions that prefer to be executed in chunks due to some high-fixed overhead like packet headers or making connections. The limit is that sometimes the next action depends on the result of a previous one in which case, all pending actions are executed at once.

Example:

mySession :: Session IO ()
    a <- readit  -- nothing happens yet
    b <- readit  -- nothing happens yet
    c <- readit  -- nothing happens yet
    if a       -- all three readits execute because we need a
      then write "a"
      else write "..."
    if b || c  -- b and c already available
      ...

This reminds me of so many Haskell concepts but I can't put my finger on it.

Of course, you could do something obvious like:

[a,b,c] <- batch([readit, readit, readit])

But I'd like to hide the fact of chunking from the user for slickness purposes.

Not sure if Session is the right word. Maybe you can suggest a better one? (Packet, Batch, Chunk and Deferred come to mind.)

Update

I think there was a really good answer last night that I read on my phone but when I came back to look for it today it was gone. Was I dreaming?

Upvotes: 4

Views: 147

Answers (3)

Jeremy List
Jeremy List

Reputation: 1766

You could use the unsafeInterleaveIO function. It is a dangerous function that can introduce bugs to your program if not used carefully, but it does what you're asking for.

You can insert it into your example code like this:

lazyReadits :: IO [a]
lazyReadits = unsafeInterleaveIO $ do
  a <- readit
  r <- lazyReadits
  return (a:r)

unsafeInterleaveIO makes the action as a whole lazy, but once it starts evaluating it will evaluate as if it had been strict. This means in my above example: readit will run as soon as something tests whether the returned list is empty or not. If I'd used mapM unsafeInterleaveIO (replicate 3 readit) instead, then readit would only be run when the actual elements of the list are evaluated, which would make the contents of the list depend on the order in which its elements are inspected, which is one example of how unsafeInterleaveIO can introduce bugs.

Upvotes: 0

ErikR
ErikR

Reputation: 52049

This is very similar to what Haxl does.

For more info:

Upvotes: 1

rampion
rampion

Reputation: 89113

I don't think you can do exactly what you want, since what you describe exploits haskell's lazy evaluation to have the evaluation of a force the actions that compute b and c, and there's no way to seq on unspecified values.

What I could do was hack together a monad transformer that delayed actions sequenced via >> so that they could be executed all together:

data Session m a = Session { pending :: [ m () ], final :: m a }                    

runSession :: Monad m => Session m a -> m a                                         
runSession (Session ms ma) = foldr (flip (>>)) (return ()) ms >> ma                            

instance Monad m => Monad (Session m) where                                         
  return = Session [] . return                                                      
  s >>= f = Session [] $ runSession s >>= (runSession . f)                          
  (Session ms ma) >> (Session ms' ma') =
    Session (ms' ++ (ma >> return ()) : ms) ma'

This violates some monad laws, but lets you do something like:

 liftIO :: IO a -> Session IO a  
 liftIO = Session []             

 exampleSession :: Session IO Int
 exampleSession = do             
   liftIO $ putStrLn "one"       
   liftIO $ putStrLn "two"       
   liftIO $ putStrLn "three"     
   liftIO $ putStrLn "four"      
   trace "five" $ return 5

and get

ghci> runSession exampleSession
five
one
two
three
four
5
ghci> length (pending exampleSession)
4

Upvotes: 3

Related Questions