1. 13

  2. 9

    I wonder if it would be pedagogically better to just explain what do-notation desugars to instead of using an analogy (“assignment”). I think that’s what it took for me to “get” do-notation. I’m not sure about that, though. Jumping straight to the ground truth might be a bit jarring for someone coming from an imperative language.

    1. 4

      I don’t think it’s useful to call this assignment at all. I end up just having to rollback bad analogies later when it leads to false intuition. That ends up being more work than “don’t worry about it” or “here’s how it desugars.”

      1. 2

        Exactly what I was thinking about.

        This is the approach used in the Real-World Haskell book when they introduce monads.

        Making explicit both the bind (>>=) and then (>>) type signatures are a good start to trigger some kind of intuition about monads.

      2. 1

        Hmm .. I’m afraid I don’t buy this at all. You can’t take

        let x = expensiveComputation () in x + x

        and replace it by

        expensiveComputation () + expensiveComputation ()

        and expect it to run the same. Of course, the Haskell experts amongst us know that denotationally the expressions are equal, but they’re certainly not operationally equal. I have to say I agree with bitemyapp here. There’s a perfectly sane and comprehensible operational reading of Haskell code and it doesn’t make any sense to pretend that the denotational semantics is the most important thing.