Am Fr., 21. Okt. 2022 um 16:31 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

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

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.

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

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

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

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.

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

And it's not one of its goals.