Since the early 2000s, the RebindableSyntax language extension was our only choice if we wanted to use do-notation with anything other than instances of the Monad type class. This design became particularly unwieldy a few years ago, when we started introducing linear monads in our experiments with -XLinearTypes. In this post we will discuss how QualifiedDo, a new language extension in the upcoming 8.12 release of GHC, improves the experience of writing do-notation with monad-like types.

Do-notation

All Haskellers are accustomed to do-notation. Mark Jones introduced it in the Gofer compiler in 1994, and from there it made it into the Haskell language report in 1996. Since then it has become popular, and for a good reason: it makes easy to read a sequence of statements describing an effectful computation.

f :: T String
f = do h <- openAFile
       s <- readTheFile h
       sendAMessage s
       closeTheFile h
       waitForAMessage

One just reads it top-to-bottom. There are no parentheses and no operator precedences to figure out where statements begin and end.

Because monads are the main abstraction for dealing with effectful computations in Haskell, it made sense to support do-notation for instances of the Monad type class, which means that the type T above needs to have a Monad instance.

class Applicative m => Monad m where
  return :: a -> m a
  (>>=) :: m a -> (a -> m b) -> m b

instance Monad T where
  ...

Monad-like

In the new century, new ideas appeared about how to represent effectful programs. A growing collection of monad-like types accumulated for which the Monad type class was an inadequate abstraction. Such has been the case of indexed monads, graded monads, constrained monads and, lately, linear monads.

In the case of linear monads, the operations use linear arrows, which prevents us from using them to implement the standard Monad type class.

{-# LANGUAGE LinearTypes #-}
module Control.Monad.Linear where

-- constraints elided for the sake of discussion
class (...) => Monad m where
  return :: a #-> m a
  (>>=) :: m a #-> (a #-> m b) -> m b

(>>) :: Monad m => m () #-> m b #-> m b
m0 >> m1 = m0 >>= \() -> m1

Until now, the way to use do-notation with not-quite-monads has been to use the RebindableSyntax language extension. With RebindableSyntax, we need only to bring into scope the operations that do-notation should use.

{-# LANGUAGE RebindableSyntax #-}
import Control.Monad.Linear as Linear

instance Linear.Monad LinearT where
  ...

f :: LinearT String
f = do h1 <- linearOpenAFile
       (h2, Unrestricted s) <- linearReadTheFile h1
       linearLiftIO (sendAMessage s)
       linearCloseTheFile h2
       linearWaitForAMessage

Now the compiler will desugar the do block as we want.

f :: LinearT String
f = linearOpenAFile Control.Monad.Linear.>>= \h1 ->
    linearReadTheFile h1 Control.Monad.Linear.>>= \(h2, Unrestricted s) ->
    linearLiftIO (sendAMessage s) Control.Monad.Linear.>>
    linearCloseTheFile h2 Control.Monad.Linear.>>
    linearWaitForAMessage

RebindableSyntax, however, has other effects over the whole module. Does your module have another do block on a regular monad?

sendAMessage s =
  do putStr "Sending message..."
     r <- post "https://tweag.io/post" s
     if statusCode r == 200
     then putStrLn "Done!"
     else putStrLn "Request failed!"

The compiler will complain that there is no instance of Linear.Monad IO. And indeed, there is not supposed to be. We want the operations of Monad IO here! But aren’t Prelude.>> and Prelude.>>= in scope anymore? No, they’re not in scope, because RebindableSyntax also has the effect of not importing the Prelude module implicitly.

If function sendAMessage had a type signature, GHC would complain that IO is not in scope.

sendAMessage :: String -> IO ()

It gets worse:

...
  if statusCode r == 200
  then putStrLn "Done!"
  else putStrLn "Request failed!"
...

There would be:

• no putStrLn in scope
• no fromInteger to interpret the literal 200
• no ifThenElse function that -XRebindableSyntax mandates to desugar an if expression

To add insult to injury, in the particular case of linear types, there is not even a correct way to define an ifThenElse function to desugar if expressions. So enabling -XRebindableSyntax together with -XLinearTypes deprives us from if expressions in linear contexts.

The list of problems does not end here, but the remaining issues are already illustrated. Each issue has a simple fix, all of which add up to an annoying bunch the next time we are faced with the decision to introduce RebindableSyntax or do away with do-notation.

But despair no more, dear reader. The days of agony are a thing of the past.

Qualified do

By enabling the QualifiedDo language extension, we can qualify the do keyword with a module alias to tell which operations to use in the desugaring.

{-# LANGUAGE QualifiedDo #-}
import qualified Control.Monad.Linear as Linear

instance Linear.Monad LinearT where
  ...

f :: LinearT String
f = Linear.do                                      -- Desugars to:
      h1 <- linearOpenAFile                        -- Linear.>>=
      (h2, Unrestricted s) <- linearReadTheFile h1 -- Linear.>>=
      linearLiftIO (sendAMessage s)                -- Linear.>>
      linearCloseTheFile h2                        -- Linear.>>
      linearWaitForAMessage                        -- Linear.>>

sendAMessage :: String -> IO ()
sendAMessage s = do                       -- Desugars to:
    putStr "Sending message..."           -- Prelude.>>
    r <- post "https://tweag.io/post" s   -- Prelude.>>=
    if statusCode r == 200
    then putStrLn "Done!"
    else putStrLn "Something went wrong!"

This has the compiler desugar the Linear.do block with any operations Linear.>>= and Linear.>> which happen to be in scope. The net result is that it ends up using Control.Monad.Linear.>>= and Control.Monad.Linear.>>. The unqualified do still uses the >>= and >> operations from the Prelude, allowing different desugarings of do-notation in a module with ease.

Is that it? Yes! Really? No extra effects on the module! One can combine QualifiedDo with ApplicativeDo, or RecursiveDo and even RebindableSyntax. Only the qualified do blocks will be affected.

Every time that a do block would need to reach out for mfix, fail, <$>, <*>, join, (>>) or (>>=), Linear.do will use Linear.mfix, Linear.fail, Linear.<$>, etc.

The proposal

An extension being this short to explain is the merit of more than a year-long GHC proposal to nail each aspect that could be changed in the design.

We had to consider all sorts of things we could possibly use to qualify a do block. How about qualifying with a type class name? Or a value of a type defined with record syntax? Or an expression? And expressions of what types anyway? And what names should be used for operations in the desugaring? And should the operations really be imported? And what if we wanted to pass additional parameters to all the operations introduced by the desugaring of a given do block?

There is an answer to each of these questions and more in the proposal. We thank our reviewers, with a special mention to Iavor Diatchki, Joachim Breitner, fellow Tweager Richard Eisenberg, and Simon Peyton Jones, who devoted their energy and insights to refine the design.

What’s next?

Reviewers have suggested during the discussion that other syntactic sugar could be isolated with qualified syntax as well: list comprehensions, monad comprehensions, literals, if expressions or arrow notation are candidates for this.

For now, though, we are eager to see how much adoption QualifiedDo has. The implementation has recently been merged into GHC, and we will be able to assess how well it does in practice. The extension is now yours to criticize or improve. Happy hacking!