[daenz]

I feel like I'm in a unique place of learning Haskell, so I'll try to translate the last line of your first function:

  return . fromMaybe defaultPort $ maybeEnvPort >>= readMaybe

Basically this is composing a function out of "return" and "fromMaybe" (using the composition operator "."), then partially applying defaultPort to that composed function, so you now have a function that takes one argument. The resulting function is then applied (using $) to the result of "maybeEnvPort >>= readMaybe".

In "maybeEnvPort >>= readMaybe", ">>=" is an infix function that takes maybeEnvPort as its first argument (which is a Maybe Monad), "unpacks" it, applies "readMaybe" to the unpacked result. readMaybe returns another Maybe Monad.

The result of everything after the $ is a Maybe Monad that contains the port from the environment, or a failure condition. The result of applying the composed-and-partially-applied function (from before the $) to it is that the port from the environment is chosen if it didn't fail, otherwise the defaultPort is used, and then the whole thing is wrapped in an IO Monad.

[chowells]

The only place I would offer a correction is to say that values aren't monads. "Maybe Monads" and "IO Monads" aren't getting created or passed around because only values exist at runtime.

The only thing that can be a Monad is a type. You could say you have a value of a monadic type, I suppose...

But that gets into something I've learned over time answering beginner questions. Call things types or values. "a Maybe value" (this is a little sloppy, but perfectly fine in conversation) or "the IO type". Don't call types with a Monad instance "Monads" except in the case when you are talking about all of them generically. "The IO Monad" is an incredibly self-limiting and distracting way to think about the IO type. There's nothing inherently interesting about being a Monad. Why not call it "the IO Functor" or "the IO Alternative" or even "the IO MonadRandom"? Those are all instances the type has. None are particularly more important than the rest. Sometimes what you want to do is most easily done via a type class other than Monad. Don't tie yourself so much to a single detail. This is actually really important, because our habits shape our intellectual exploration. When you find a habit that shoehorns you into one direction, it's a good idea to try to weaken it.

[platz]

i like it, for some reason my brain dislikes switching from left/right a lot, so that's why i often avoid the $ operator, so instead I'd write:

    return . fromMaybe defaultPort (maybeEnvPort >>= readMaybe)

[dllthomas]

"Have the data flow in one direction" is a good rule of thumb in writing clear Haskell code.

That said, your conversion away from $ changes the meaning here (in a way that doesn't typecheck, I think - remember that regular function application binds tightest whereas dollar binds loosest) and you still don't achieve your goal.

Instead, maybe

   return . fromMaybe defaultPort $ readMaybe =<< maybeEnvPort

or even

   return $ fromMaybe defaultPort $ readMaybe =<< maybeEnvPort

If you still don't like the dollar signs, we can parenthesize instead in two correct ways, although I don't find them more readable:

    (return . fromMaybe defaultPort) (readMaybe =<< maybeEnvPort)

    return (fromMaybe defaultPort (readMaybe =<< maybeEnvPort))