Prefer do notation over Applicative operators when assembling records (2024)

This is a short post explaining why you should prefer do notation when assembling a record, instead of using Applicative operators (i.e. (<$>) / (<*>)). This advice applies both for type constructors that implement Monad (e.g. IO) and also for type constructors that implement Applicative but not Monad (e.g. the Parser type constructor from the optparse-applicative package). The only difference is that in the latter case you would need to enable the ApplicativeDo language extension.

The guidance is pretty simple. Instead of doing this:

data Person = Person
{ firstName :: String
, lastName :: String
}
getPerson :: IO Person
getPerson = Person <$> getLine <*> getLine

... you should do this:

{-# LANGUAGE RecordWildCards #-}
{-# OPTIONS_GHC -Werror=missing-fields #-}
data Person = Person
{ firstName :: String
, lastName :: String
}
getPerson :: IO Person
getPerson = do
firstName <- getLine
lastName <- getLine
return Person{..}

Why is the latter version better? There are a few reasons.

Ergonomics

It's more ergonomic to assemble a record using do notation because you're less pressured to try to cram all the logic into a single expression. For example, suppose we wanted to explicitly prompt the user to enter their first and last name. The typical way people would extend the former example using Applicative operators would be something like this:

getPerson :: IO Person
getPerson =
Person
<$> (putStrLn "Enter your first name:" *> getLine)
<*> (putStrLn "Enter your last name:" *> getLine)

The expression gets so large that you end up having to split it over multiple lines, but if we're already splitting it over multiple lines then why not use do notation?

getPerson :: IO Person
getPerson = do
putStrLn "Enter your first name:"
firstName <- getLine
putStrLn "Enter your last name:"
lastName <- getLine
return Person{..}

Much clearer! Also, the version using do notation doesn't require that the reader is familiar with all of the Applicative operators, so it's more approachable to Haskell beginners.

Order insensitivity

Suppose we take that last example and then change the Person type to reorder the two fields:

data Person = Person
{ lastName :: String
, firstName :: String
}

... then the former version using Applicative operators would silently break: the first name and last name would now be read in the wrong order. The latter version (using do notation) is unaffected. More generally, the approach using do notation never breaks or changes its behavior if you reorder the fields in the datatype definition. It's completely order-insensitive.

Better error messages

If you add a new argument to the Person constructor, like this:

data Person = Person
{ alive :: Bool
, firstName :: String
, lastName :: String
}

... and you don't make any other changes to the code then the former version will produce cryptic error messages about type mismatches. Whereas the latter version produces a much more direct error message indicating which fields of 'Person' are not initialized. This error message more clearly suggests to the developer what needs to be fixed: the alive field needs to be initialized.

Caveats

This advice obviously only applies for datatypes that are defined using record syntax. The approach I'm advocating here doesn't work at all for datatypes with positional arguments. However, this advice does still apply for type constructors that are Applicatives and not Monads; you just need to enable the ApplicativeDo language extension.