Earlier quoted context omitted.
Ouch. That function is actually written in a pretty convoluted and redundant way. getSocketAPIPort :: Int -> IO Int getSocketAPIPort defaultPort = do maybeEnvPort >= readMaybe That's starting to border on over-terse, so you could expand the bind operator into do notation if you wanted to spread it out a bit further. On the other hand, it's also starting to feel over-verbose, using do notation for only a single IO act…
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 func…
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.