Haskell – Should do-notation be avoided in Haskell

do-notationfunctional-programminghaskelliomonads

Most Haskell tutorials teach the use of do-notation for IO.

I also started with the do-notation, but that makes my code look more like an imperative language more than a FP language.

This week I saw a tutorial use IO with <$>

stringAnalyzer <$> readFile "testfile.txt"

instead of using do

main = do
    strFile <- readFile "testfile.txt"
    let analysisResult = stringAnalyzer strFile
    return analysisResult

And the log analysis tool is finished without the do.

So my question is "Should we avoid do-notation in any case?".

I know maybe do will make the code better in some cases.

Also, why do most tutorials teach IO with do?

In my opinion <$> and <*> makes the code more FP than IO.

Best Solution

do notation in Haskell desugars in a pretty simple way.

do
  x <- foo
  e1 
  e2
  ...

turns into

 foo >>= \x ->
 do
   e1
   e2

and

do
  x
  e1
  e2
  ...

into

x >>
do 
  e1
  e2
  ....

This means you can really write any monadic computation with >>= and return. The only reason why we don't is because it's just more painful syntax. Monads are useful for imitating imperative code, do notation makes it look like it.

The C-ish syntax makes it far easier for beginners to understand it. You're right it doesn't look as functional, but requiring someone to grok monads properly before they can use IO is a pretty big deterrent.

The reason why we'd use >>= and return on the other hand is because it's much more compact for 1 - 2 liners. However it does tend to get a bit more unreadable for anything too big. So to directly answer your question, No please don't avoid do notation when appropriate.

Lastly the two operators you saw, <$> and <*>, are actually fmap and applicative respectively, not monadic. They can't actually be used to represent a lot of what do notation does. They're more compact to be sure, but they don't let you easily name intermediate values. Personally, I use them about 80% of the time, mostly because I tend to write very small composable functions anyways which applicatives are great for.

Related Question