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

Indeed it does, as do many other languages. IMHO this is a misfeature.

Common Lisp guarantees a left-to-right order for evaluation (section
3.1.2.1.2.3 Function Forms, <http://clhs.lisp.se/Body/03_ababc.htm>) and
precedence of all kinds. This makes things easier to understand.

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

The proposal serves two purposes:

(1) A comment to programmers.

(2) A hint to compilers.

A comment works just as well by always using the same order, and merely
saying that it doesn't matter.

A compiler hint only matters if the optimizer can make the code run
faster. Then the compiler needs some way to estimate the cost of each
expression. If it can produce reliable estimates, it can probably infer
enough to construct a dependency graph by itself, in which case
re-ordering a standard "begin" would do as well.

If we're going for compiler hints, we could have something like:

(perform* (foo) (bar) (baz) (qux))

where the programmer is hinting that (foo) probably runs fastest and
(qux) slowest. But unless the compiler parallelizes the expressions, the
total runtime is probably not much dependent on the order.

I linked to Schemik because they did some research about using this kind
of evaluator at the language level. IIRC it's based on a thread pool.

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

Yes, it's good for textbooks. But it doesn't harm a textbook if an
implementation always runs the code in the same order.

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

I feel I understood your point of view, but don't agree with it.

My main point is that re-ordering without proof of equivalence obscures
an intrinsic property of imperative programming which people should be
aware of. Your point is that a human can supply the proof; my
counterpoint is that humans are known to be bad at such proofs.

It would be great if computers worked declaratively but they don't, and
pretending that they do always bites people eventually. The remedy is to
enforce clear boundaries between the imperative and declarative parts of
a system, which this proposal does not do.