Good question. "Do notation" is sometimes referred to as "the programmable semicolon", because how you go from one statement to the next depends on which monad you're in. (In the List example, the assignment `x <- [1, 2, 3]` forked execution three ways before proceeding to the next assignment.)

In Java, the semicolon is pretty much fixed; you can't change the relationship between statements in any meaningful way. So you have to play tricks. You can implement the List example in a crafty but leaky way:

    do(() -> {
      var x = choose(1, 2, 3);
      var y = choose(4, 5, 6);
      return x + y;
    });

When `choose` is called for the first time, it remembers which choice it returns to you. When you `return` from the block, your result is stored, and then the function is re-executed -- except this time, `choose` will now return a different value (the next one). You can implement this in a rather small handful of lines, but it's very tight and clever code, and not at all obvious how it works at first glance.

There's another way to do this, with chained `flatMap` calls, like:

    list(1, 2, 3).flatMap(x ->
      list(4, 5, 6).flatMap(y ->
        list(x + y)));

...but that's so different from "normal" use of a language like Java that readers and writers alike are likely to balk to some extent.

'do' in Haskell is like PROGN right?

I guess in a OOP langague like C++ it would be something like:

foo1(); foo2(); return foo3();

?

Do isn't a pattern, its a notation for monad operations. Any pattern implementable in it can be reproduced in any language where there are objects which support monad operations by using those operations directly. Some languages (e.g., Scala and its comprehensions, which use monad operations rather than imperative operations over collections the way Python does) also have a do-notation-like syntax sugar, as well.

Monads and 'do' and stuff are just a form of abstract control structure. They're hiding information about the actual nature of a computation, making it look like a bit of imperative code, but in the background they could be doing anything. To be honest, despite the mystique, this isn't so different to virtual calls in an OO language, or just having objects hide their internals. Can you create an algorithm accepting the same steps but performing some magic in the background, around and in between every step? You have decorators, iterators, visitors, all that sort of stuff, so the answer is probably yes. Monads happen to be a very simple way to do this, and so you end up with entire ecosystems and fundamental ways of thinking built on that pattern.