Hacker News Reader

A lot of people dislike the terseness of that style (especially the use of operators.) I'm not one of those people, but I can understand their point of view. Fortunately, Haskell also lets us write code in a way that managers can understand.

    getCuteCat img = do
        cropped <- findCat img
        withTie <- addBowTie cropped
        withSparkles <- makeEyesSparkle withTie
        return (addRainbow (makeSmaller withSparkles))

And, with this translation, I hope everyone can see how exceedingly simple the >>= operator is: “take the return value of what’s to the left of me and deliver it as an argument to the function to the right of me”.

(Nitpick: if we’re translating kccqzy’s example verbatim, the last line shouldn’t include return, since — as per his definition — addRainbow is monadic)

However this style breaks down as soon as you have to do something more complicated than thread a single value, or have to do something more complicated than pass failures through.

We've been using this style a lot in Elixir via the `with` macro

    def get_cute_cat(image_id) do
      with {:ok, cropped}       <- find_cat(image_id),
           {:ok, with_tie}      <- add_bowtie(cropped),
           {:ok, with_sparkles} <- make_eyes_sparkle(with_tie)
      do
        with_sparkles 
        |> make_smaller() 
        |> add_rainbow()
      end
    end

If any of the values on the rhs of a `<-` cannot be pattern matched, it returns up the returned value. This value can be pattern matched easily inside an `else` clause underneath the main block. The use of the `:ok,` vs `:error,` tuple convention allows multiple values to be destructured and passed around if needed (rather than an optional type).

If you find the code getting unwieldily, as runeks said you can break it down into simpler constructs.

Code can always be broken up into simpler sub-components. The more you logically compartmentalize your code, the more it lends itself to these simple transformations. At the end of the day, you — not the problem you’re trying to model — decide how much you want to do in each function.

Naive question, how do I figure out in which part of the chain a null had occured? Or is the assumption that you'd establish only valid inputs and therefore never have a chance for this to happen?

The Maybe monad doesn’t have this feature. It’s purposefully simple: the value is either present or absent.

If you want different errors, use the Either monad. It basically means either the value you want is there, or it’s not there but there’s an explanation. Chaining works just as well for the Either monad.

> Yes Rust has .and_then which is same as >>= (sometimes also called flatMap or bind), but still the syntax isn’t lightweight enough.

Rust has try! and ?. The latter is quite lightweight.

These are not replacements for >>= because they don’t work with other monads. For example you cannot use try! and ? on lists/vectors.