[kccqzy]

That’s only true when you use the IO monad as an Applicative. It’s not true if you use for example the Concurrently type from the async package (which is quite wonderful btw). The ApplicativeDo language extension makes it possible for you to use do notation in this case as well.

https://hackage-content.haskell.org/package/async-2.2.6/docs...

[throwway262515]

Do you have a concrete example using Concurrently where the effect semantics is harder to understand--possibly even misleading--with effect combinators than with do notation?

[tome]

Here's a silly but simple example:

    newtype FlippedIO a = MkFlippedIO { runFlippedIO :: IO a }
      deriving Functor
    
    instance Applicative FlippedIO where
      pure = MkFlippedIO . pure
      liftA2 f (MkFlippedIO x) (MkFlippedIO y) =
        MkFlippedIO ((flip . liftA2 . flip) f x y)
    
    data Person = Person String String
      deriving Show
    
    putStrLnFlipped = MkFlippedIO . putStrLn
    
    getLineFlipped = MkFlippedIO getLine
    
    getPerson :: IO Person
    getPerson = runFlippedIO $
      Person
        <$> (putStrLnFlipped "Enter your first name:" *> getLineFlipped)
        <*> (putStrLnFlipped "Enter your last name:"  *> getLineFlipped)

It runs things "backwards":

    ghci> getPerson
    One
    Enter your last name:
    Two
    Enter your first name:
    Person "Two" "One"

[kccqzy]

When you use Concurrently you are implying that you want things to happen concurrently and you don’t care about effect ordering. You leave the effect ordering to the GHC runtime in how it schedules these green threads. Using do notation here works but it is slightly misleading. A seasoned Haskeller would never see do notation and assume anything about the ordering of effects.