Am Fr., 21. Okt. 2022 um 15:17 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:
>
>
> > On Oct 21, 2022, at 9:03 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
> >
> >>
> >> 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.
> >
> > 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.
>
> I think Marc meant that the “perform” form is both a message to the compiler and to whoever is reading the code.

Yes; and it is also not true that it is just simply an unchecked
comment.  Given compiler support, you could run your test cases in
such a way that the implementation chooses a random permutation for
each procedure call evaluation and for each "perform".  Now if you had
written your algorithm as `(perform (foo) (bar))` because you thought
that the order wouldn't matter but testing suddenly proves
differently, it would be better than if you had written `(begin (foo)
(bar))` where the order is, accidentally, one where the error wouldn't
occur but where, in fact, you don't learn that you actually hadn't
understood your algorithm.