Am Sa., 15. Okt. 2022 um 04:36 Uhr schrieb Vladimir Nikishkin
<xxxxxx@gmail.com>:
>
> Dear SRFI contributors,
> Dear Mark
>
> This SRFI looks very straightforward, however, I am feeling that there
> is more to it than it seems.
>
> At the moment, as it is written, it seems perfectly valid to spawn a
> separate thread (or a green thread) per expression within a (perform )
> form. And also perfectly valid not to. However, if one tries to
> manually sequence those expressions using mutexes and waiting, the
> first (threaded) case will work, whereas the second will fail. And
> there seems to be no a priori way to distinguish between these two
> cases.

This SRFI uses the same language as the R7RS. There are no threads
involved as much as an implementation does not spawn threads when
evaluating a procedure call like (<proc-expr> <expr1> <expr2>).

> Additionally, it seems to be useful to have a form that is almost like
> "perform", but actually tries to randomise the evaluation order each
> time it is used. Useful in that it would make broken code that
> actually relies on evaluation order unbeknownst to a newbie programmer
> fail with high probability, rather than silently succeeding on an
> implementation A and fail with low probability on an implementation B.

The perform form itself does not demand randomization. However,
neither does it prohibit it. So a Scheme system implementing this SRFI
is invited to offer a debug mode which implements randomization of the
perform form but also of evaluating procedure call arguments.