Am Fr., 21. Okt. 2022 um 15:03 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> 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".

Scheme already evaluates procedure arguments in an arbitrary order. So
maybe Scheme is not the language you are looking for.

> 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".

First of all, allowing more compiler optimization is only a byproduct
of the proposal.  That said, in general (!), an optimizer cannot prove
that the evaluation order of two expressions doesn't matter.

Moreover, maybe there is even a difference when it comes to the order,
but that difference is not relevant to the program's scope.  An
optimizer couldn't know this.

> >> 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.

And they do, with or without a "perform" form.  You construct a
dichotomy where there would be only one if your intention differed
from what you programmed.  SRFI 236 makes it actually easier to write
down your intention.

We mustn't forget that a programming language like Scheme is used not
only to feed compilers but also to codify algorithms.  For the latter
use case, SRFI 236 is more relevant.

> 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.

I have the feeling that we are talking past each other...