[tel]

Sure.

A little while ago there was an article (https://news.ycombinator.com/item?id=9907435) which suggested code like

    if (cond1)
      return val1;
    if (cond2)
      return val2;
    if (cond3)
      return val3;

    return defaultVal;

is simpler and better than

    if (cond1) {
      return val1;
    } else if (cond2) {
      return val2;
    } else if (cond3) {
      return val3;
    } else {
      return defaultVal;
    }

or something like that. In a certain sense this is objectively false as the second one uses fewer features than the first (a statement we can make formal using monads, but that's unrelated). I'd argue this is doubly true because whenever non-linear flow control begins to be used pervasively it is hard to know what code will be executed and under what conditions. With nesting at least these conditions are obvious.

In any case, we can solve this conundrum through the existence of an Option or Maybe type which encapsulates the imperative behavior of short-circuiting failure directly and limits it's scope.

[yoz-y]

If we have let's say:

    fa.then( f(ra) {
      return fb(ra);
    }).then( f(rb) {
      return fc(rb);
    })

rather than (if I understand the monadic way of doing things correctly)

    ra <- fa()
    rb <- fb(ra)
    rc <- fb(rb)

How is the scope of the short-circuiting limited? We will obtain a None result in case of error but we still do not know when the error occurred. Granted, we can add some guards but so can we with promises. Since the return statements are always at the end of each separate function the scope should not be a problem?

I am kind of new to this so please bear with me. Thanks.

[tel]

Np!

The idea is that from "inside", as we are using do-notation, we merely think of working in an imperative language where failure might occur and short circuit things while from "outside" we see the type of this computation as Maybe and can examine whether or not it actually failed. The "inside"/"outside" dynamic is the scope delimitation.