>> Common Lisp guarantees a left-to-right order for evaluation

> It leads to an over-specification, which is, in my point of view, bad.
>
> In the case of `let` and `letrec`, Scheme also allows arbitrary
> evaluation orders. From a theoretical point of view, this is great
> because it makes Scheme more expressive. This may not be important for
> every programmer, but at least for me, as a mathematician, it is.

The point of a high-level language is not to permit all expressions, but
to permit the kinds of expressions that are easy to use correctly.

Things that are hard to reason about are only excused by optimization,
and should be tucked into an "unsafe" corner of the language which is
ordinarily out of reach. As CL does: (declare (optimize (safety 0))).

What's hard to reason about is mainly choices of different kinds, and
arbitrarily varying choices are hardest of all.

> If you prescribe the evaluation order, you make some kinds of tests
> impossible (see my previous post).

Building programs out of features that are hard to reason about is what
makes heavy testing necessary. There's no upper limit to how many tests
you need if the tools and standards are tricky enough. Fuzz testing is
largely profitable because C is too expressive for the problems people
apply it to, and internet standards are too complex and made out of
unreliable parts (e.g. subtle parsing).

No program is a mathematically (let alone philosophically) pure
description of how to solve a problem. Every program is encoded for a
particular abstract machine. IMHO it's not generally useful to point out
all the ways in which the description could be different while still
working correctly. There are arbitrarily many of them.

> My point is a different one. My point is that it is bad if you have no
> idea why a certain order is important but happen to find that a
> particular order enclosed in "begin" just works.

Good programmers rarely code by guesswork. As for documentation, I
haven't seen evidence that more detailed comments and annotations lead
to better code. In my experience code is either inspired or not, and
annotating bad code does not make it better.