>> The compiler's optimizer should be free to re-order or parallelize
>> expressions whenever it can prove the effect stays the same.

> Yes, and the SRFI 236 expression form does leave it to the compiler
> where as a "begin" would impose an order (which is not good if the
> programmer has to choose an arbitrary order).

Imperative programming is inherently full of arbitrary choices of order.

You can always use the same order, or you can "randomize" the order. The
latter only makes sense when dependencies between effects are known.

Decades of experience demonstrate that the human brain is bad at
enumerating dependencies between things. Makefiles routinely have bugs;
and/or logical expressions with arbitrary evaluation order cause bugs.
Programs using threads can barely be reasoned about.

If things always run in the same order, a bug always manifests the same
way. If the order varies, you get "heisenbugs".

We should only eschew an explicit execution order when the dependency
graph is known to be correct by construction. Scheme gives no tools to
help with this (we don't have effect types, inference of which functions
are pure, etc.) Approaches that mix imperative and declarative result in
predictable (and often avoidable) problems.

Doesn't RnRS imply that "begin" runs "as if" the expressions are in the
given order? Optimizers can eliminate entire sections of code that are
redundant, so surely they can rearrange a "begin".

>> culture that is endemic in C and C++. It leads to bugs and obscure code.

> It's exactly the opposite. Leaving possible compiler optimizations
> aside, it is about documenting your program and clarifying your
> intention.

Documentation is the problem, not the solution. (Unless you're writing a
textbook.) Computers follow instructions, not intent. Absent automated
proofs, it's better if they follow them as predictably as possible.

I've largely stopped writing comments. Since the compiler doesn't check
them, they end up incorrect as often as correct. The same goes for all
kinds of unchecked declarations.

> When you write "begin," you make clear that the order matters because
> of the dragons.

I wouldn't expect anybody to see "begin" that way. We use it because we
live in an imperfect world, and "begin" is what we have. A "perform"
will make the world differently imperfect without solving any
fundamental problems.

> When you write  "perform", you
> make clear that the order does not matter for the algorithm you have
> in mind, on the other hand.

Unless the code has bugs, in which case you're obscuring the code.
Language constructs should make it easy to write correct code.
Optimization and annotation are secondary concerns that hurt as often as
they help IMHO.