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

I don't think that you can sort every concept into black and white here.

Actually, my idea of the "perform" form was born from problems arising
from a piece of imperative code, which would have benefited - at least
in my mind - from a perform form.  Most forms of imperative code are
not easy to use correctly, but only a few programming languages are as
radical as Haskell.

Or take first-class continuations (delimited or not).  They make code
hard to reason about, but (as I think) they have their niche in
well-encapsulated modules.

Or take things like "unfold" from SRFI 1. Probably harder to use
correctly than a hand-written loop, but when done well makes the
programmer's intention (and the mathematical concept behind) much
clearer.

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

Here we have to agree that we disagree.  I find it harder to reason
when superficial assumptions are made (like the order of evaluation
when it doesn't matter).

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

The existence of a "perform" form does not increase the need for
tests.  But it does allow for logic tests that weren't possible
beforehand.

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

Sure, there are limits. But one of Scheme's virtues is that it is
amongst the most expressive languages (where expressiveness matter).

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

Good code can be even better if the programming language removes the
need to obscure the algorithmic idea behind the code.

In any case, we probably fundamentally disagree on that part of
Scheme, which is touched by this SRFI.  Thus, it is probably pointless
to carry this discussion further.  If I understand you, you think it
is best to withdraw this SRFI.  From my point of view, many points you
raised speak actually for this SRFI.