Escaping Hell with Monads (2017)
I think this is another instance of solving the wrong problem.<p><pre><code>    var a = getData();
    if (a != null) {
      var b = getMoreData(a);
      if (b != null) {
        var c = getMoreData(b);
        if (c != null) {
          var d = getEvenMoreData(a, c)
          if (d != null) {
            print(d);
          }
        }
      }
    }
</code></pre>
Why not simply<p><pre><code>    var a = getData();
    if (a == null)
        return;

    var b = getMoreData(a);
    if (b == null)
        return;

    var c = getMoreData(b);
    if (c == null)
        return;

    var d = getEvenMoreData(a, c)
    if (d == null)
        return;

    print(d);
</code></pre>
And the other example<p><pre><code>    var a = getData();
    for (var a_i in a) {
      var b = getMoreData(a_i);
      for (var b_j in b) {
        var c = getMoreData(b_j);
        for (var c_k in c) {
          var d = getMoreData(c_k);
          for (var d_l in d) {
            print(d_l);
          }
        }
      }
    }
</code></pre>
Yes, there is the issue that there is too much nesting. But there is no point in tackling this problem with a clever monad. That&#x27;s not solving the issue, it&#x27;s just hiding it. Operationally there is no difference.<p>What really needs to be done is to avoid data dependencies. It&#x27;s typically possible to do something like<p><pre><code>    for (var x in a)
        foo(x, a_state);
    for (var x in b)
        bar(x, a_state, b_state);
    for (var x in c)
        baz(x, a_state, b_state, c_state);
    for (var x in d)
        quux(x, a_state, b_state, c_state, d_state);
</code></pre>
This not only looks cleaner, it <i>is</i> cleaner. The path of execution is simpler. It will also often run much faster, since its only tight loops and uniform data accesses.