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.
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.